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r.mvnmR>PTNG ft. DOWNLQ AnED PROGRAM FRAGMENT, AND 
CQRRESPOtgDPIQ SYSTBI^ 

The invention relates to a protocol for manag- 
ing, a method of verifying ania a niethod of transforming 
a downloaded program fragment and the corresponding 
systems, more particularly intended for on-board data- 
processing systems having few resources available in 
terms of memory and of computing power. 

in a general way, by reference to figure la, it 
is reiterated that on-board data-processing systems 10 
include a microprocessor 11, a permanent memory, such 
as a non-writable memory 12 containing the code of the 
executable program, and a rewritable, nonvolatile, per- 
inanent memory 15 of EEPROM type containing the data 
stored in the system, a volatile, random^access memory 
14 in which the program stores its intermediate results 
while it is executing, .and input/output devices 15 al- 
lowing the system to interact with its environment. In 
the case in which the on-board data-processing system 
consists of a ndcroprocessor card, of the bank-card 
type, the input/output device 15 consists of a serial 
link allowing the card to communicate with a terminal, 
such as a card-reader terminal. 

in conventional on-board data-processing sys- 
tems, the code of the program executed by the system is 
fixed during construction of the system, or, at the 
latest, when the latter is customized before delivery 

to the final user. 

More sophisticated on-board data-processing sys- 
tems have, however, been implemented, these systems be- 
ing reprogrammable, such as microprocessor cards of the 
JavaCard type, for example. With respect to the preced- 
ing types, these reprogrammable systems add the possi- 
bility of enhancing the program aft r the system has 
been put into service, via an operation of downloading 
program fragments. Th se fragments of programs, widely 
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designated by "appl ts", will^ be designated applets or 
program fragments indiscriminately in the present d - 
scription. For a more detailed description of JavaCard 
systems, reference could us fully be made to the docu- 
raentation published by the conpany SUN MICROSYSTEMS 
INC., and in particular to the electronically available 
documentation, JavaCard techm^logy chapter, on the 
Kl^orld ^ide 

http://java.sun.com/products/javacard/index.html, June 
1999. 

figure lb illustrates the architecture of such a 
reprogrammable on-board data-processing system. This 
architecture is similar to that of a conventional on- 
board system, with the difference that the reprogramma- 
ble on-board system can moreover receive applets by way 
of one of its input/output devices, then store them in 
its permanent memory 13 from . which they can then be 
executed as a supplement to the main program. 

For reasons of portability between different on- 
board data-processing systems, applets are presented in 
the form of code, for a standard virtual machine. -Ehis 
code is not directly executable by the microprocessor 
11, tout it has to be ijiterpreted in software terms by a 
virtual machine 16, which consists of a program resi- 
dent in a non-writable pemianent memoi-/ 12. in the 
abovementioned exaB5)le of JavaCard cards, the virtual 
machine used is a subset of the Java virtual machine. 
For a description of the specifications relating to the 
Java virtual machine • and of the virtual machine" used, 
reference could usefully be made to the work published 
by Tim LINDHOLM and Frank YELLIN. entitled "The Java 
Virtual Machine Specificaticxn-. Addison-Wesley 1996, 
and to the documentation published by the company SON 
MICROSYSTEMS INC. -JavaCard 2.1 Virtual Machine Speci- 
fication", documentation available electronically on 
the www site http://java.sun.com/products/javacard/ 

JCVMSpec.pdf, March 1999. 



YfO 01/14958 

The operation of downloading applets onto an on- 
board data-processing system in service poses consider- 
able security problems. An applet «hich is involuntar- 
ily or even deliberately, badly written may incor- 
rectly inodify data present on the system, prevent the 
main program from executing correctly or at the right 
time, or else modify other applets downloaded previ- 
ously, making them unusable or harmful. 

AH applet written by a computer hacker may also 
divulge confidential information stored in the system, 
information such as the access code in the case of a 
bank card, for example'. At the present time, three so- 
lutions have been proposed «ith a view to remedying the 
problem of security of applets. 

A first solution coneists in using cryptographic 
signatures, so as to accept only applets originating 
from trusted bodies or persons. 

in the abovementioned example of a bank card, 
only the applets bearing the cryptographic signature of 
the bank having issued the card are accepted and exe- 
cuted by the card, any other unsigned applet being re- 
jected in the course of the dovmloading operation. An 
ill-intentioned user of the card, not having available 
encryption keys from the bank, will therefore be inca- 
pable of executing an unsigned and dangerous applet on 
the card. 

This first solution is well adapted to the case 
where all the - applets originate from the same single 
source, the bank in the abovementioned example. This 
solution is difficult to apply in the case in which the- 
applets originate from several sources, such as, in the 
exaittple of a bank card, the manufacturer of the card, 
the bank, the bodies managing- services by bank card, 
the largp commercial distribution organizations offer- 
ing clientele loyalty programs and proposing, legiti- 
mately, to download specific applets onto the card. The 
sharing and th holding among these various economic 
participants of the encryption keys necessary for the 
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. a-icmatur of the aj«)lets poee major techni- 

cal. economic and legal problems. 

second solution con.ist^ in carrying out dy- 
Cheches on access and on typing • during the execu. 

tion of the , ^^^^ carries 

In this solutxon, tne vj-xv- 
a certain n^ber of checks, during the execution of 

the applets, such as: 

. Check of acce« to the ..«»ry= ^ 
«ad or »rite in a ™a.«ry area, the virtual machine 
TeriJie. the right 6r access W the applet to the cor- 

"^^c. verification of the data t^s= upon 
.,oh instruction fro« -the a^let, the virtual ™chine 
verifies that the constraints on the data typee are 

« ..™„io the virtual machine may 
satisfied. By way of. exaiuae, the virt 

have special h«.dling for data such as valid --""^ 
aresses. and prevent the applet generating invalid 

eddresses by »ay of integer/address conversxons or 
arittenetic operations on the : addresses ; ■ . , , 

. detection of stack averflo-s and of illegal 
accesses to the execution stack of the virtual Machine 

unaer certain conditions, are likely to disturb 
U« operation thereot, to the point of circuwenting 

the preceding check mechanisms- 

this second solution allows execution of a wide 

.ange of applets under satisfactory -"'"^ 
tions. However, it features the drawback of a consider- 
le Slowing of the e«cution. caused by the r^e of 
.^amic verifications. In order to obtain a reduct.^ 

, ™- these verifications can be 

in this slowing, some of these veri 

taken charge of by the microprocessor itself, at the 
est. however, of «> increase in the complicity thereof 
and thus of the cost price of the on-board ^V^P'-- ^^ 
verifications furthez^re increase the re.;n.ir««nts for 
.andom-access and permanent memory of the »-tem by 
r ason of the additional type information which it is 
necessary to associate with the data handled. 
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A thtrd solution consists in carrying out ei 
static verification of the code of the applet during 

the downloading. ^ verification aimu- 

In this solutxon, this static 
l.te. the execution of the .pplet at the level ^ 
a... tvpes and estal>UBheB, once ^ for ^^^'J^^^ 
code of the applet conpUes with the rule of data typee 
Hd Of ac=e3. control i:^.od ^ the virtual -^-e 

doea not cause a stack av«:£lo«. If 
verification is successful, the applet can then be exe- 
without it heina necessary d^cally to ver.^ 
this rule is c»,.lied with. In the event that the 
static verification process fails, the on-board system- 
„dects the -applet, and does not allow its suhse^^t 
^.ecution. For a .ore detailed description of ^e 
^en^ntioned third solution, reference could usef^ 
be ^ to the work published by Ti» l-^om and France 
quoted above, to the ertide , published by Jan«s 
^ .GOSLING entitled 'Java Interr^ediate Byte Codes 
pwceedings of the *CM SIGFLM.. worlcshop on Inter^di- 
ate Representations (IR'95), pages lU-lW, January 
1995. and to the OS patent S.7M,964 granted on 

05/OS/1998. . 

Coni«rea with the second solution, the third so- 
lution presents the advantage of a nnaoh m>t^ rapid «e- 
cution of the applets, since the virtual n»chine does 
not carry out any verification during e^oution. 

The third solution, however, features the draw- ■ 
back of a process of static verification of the code 
«hich is cooplex and expensive, both in terms of- size 
of code necessary to conduct this process and in terms 
of si« of randoinaccess n«mory necessary to contaxn 
the intern«diat, results of the verification and- xn 
ter^s of cco-putation time. By way of illustrative e:»s.- 
ple. the code verification integrated into the Java JDK 
system «rketed by SUN KICROSYSTEMS represents about 50 
«^es of machine code, and its consumption 
^om-access >««ory is proportional to ,TP * «, . «b, 
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«h«e TP dBsigBates th »axi»m stack space. Tr desis- 
la^s ^ »axi™» nu*^. ot resist « and »b desionatea 

«axi™» nuo^er c£ b.an=hi„. tar^a.s - ^ . 
program, also widely designated by m thod. of the ap- 

Lpacitiea of the resources of O^e ^a^or.ty of the pre 
sit-day on-board data-processino syste^a, especxally 
of con<»ercially available nicroprooesaor cards. 

se,reral variants o£ the third solution have been 
proposed, in which the writer of the applet sen^ to 
L verifier, in addition to the code of the «*l.t. a 
Certain ano^t of specific supple««.tarv ^""^''Z 

:ch as precalculated data types or Pree^^l^^^e^ 
p„of of correct data typing, ror a -^.re detaxled de- 
scription of the corresponding opiating ^.des, refer- 
II could usefully be nade to tbe exticles polished 
^ Bva SOSE and Kristoffer HBGSBRO ^SB. -laghtwexght 
Stecode verification-, proceedings of the Workshop 
jor»al tJnderspinning of Java. October 1998, and to 
eeorge C. NEODIA. -Proof -Carrying Code", Proceedings of 

the 2«th ACK Syi-posiwH principles of Prosp:»«dn0 "n- 

guages, pages 106-119. respectively. 

This supplenentary information n«*es xt possible 

to verify the cod. more rapidly and slightly to reduce 
the size of the code of the verification program but 
aoes not make it possible, however, to reduce the re- 
crements for random-access m^ry. or even increases 
them, very substantially, in the case of the correct- 
data-typing preestablished-proof inforrotion. 

The object of th. present invention is to remedy 
the abovementioned drawbacks of the prior art. 

tn particul^, one subject of the present inven- 
tion is the i^le«ent«ion of a protocol for managing a 
d^nloaded program fragment, or applet, allowing e«=u- 
tlon of the latter an on-board data-processing sys- 
tem having few resources available, such as a micro- 
proc ssor card. 
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toother ^i^t ot the present inv«,tlon is also 
th« i-^lament^tion of a method of verifying a do»n- 
toLea pro^^n fragn«nt, or applet, in which a ^oc.^ 
T static verification of the code of the a^let is 
conducted «hen it is downloaded, this process possih^ 
heing aliened, at least in its principle. w.th the 
solution descried shove, hut in which new verx- 
fication techni^es.are introduced, so as to allow e..- 
lution of this verification within the limits of values 
rZor. si.e and of co^tation speed ^^^^ 
^croprocessor cards and other low-power on-hoard data- 

processing systems. „ici« 
another subject of the present invention xs also 
«,e i„pl««ntation of methods of transforrdng program 
frasments of conventional twe obtained, for ««n*l., 
^ the us. of a crava compiler on standardized PXogra« 
fragments, or applets, satisfying, a priori, 
tion criteria of the verification method which is the 

«r^i->i a view to accelerating 
subject of the inventxon, wxth a view t:o 

the process of verifying and executing them at the 
level of present-day ndcroprocessor cards or on-board 
data-processing systems. 

Another s^ibject of the present invention is. fi- 
nally, the production of on-hoard data^processing sys- 
tems allowing i««,lementation of the abovemantioned pro- 
tocol for managing and of the abovementioned method of 
verifying a downloaded program fragment as well as of 
data-processing systems allowing lit5,lem«itation of the 
methods of transforming conventional program fragments, 
or applets, into standardized program fragments, or ap- 
plets, as mentioned above. 

The protocol for managing a downloaded program 
fragment on a reprogrammable on-board eyatem, which is 
the subj ct of the pr sent invention, applies espe- 
cially to a microprocessor card equipped with a rewri- 
table memory. The program fragment consists of an ob- 
ject code, a series of instructions, executabl ^ the 
Microprocessor of the on-board system by way of a vir- 
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,,.1 ^=>.lne e^ipp a with an «xecutio» st.ck »nd with 

^^c.ian= and «^ it POS.i.Xe to ^^^^^^^^^^ 
jeot code. «.e on-board systoa is inter=onnect«I to a 

''"^ « ia noteworthy in that it consists at l.a«t. 
at the leval of the on-board system, in defctins a 
for downloading of the pro^ra^ £ra«««t » a 
Zn^ve reaponsa to the sta,e consiatina in detecting 
positive p further consiste in reading 

a downloading comnand, it further con 

the object code constituting the program ^-^^J^^ 
Tte^orarily storing this <*dect code in the r^i- 

^ry is subjected to a verification procese. instruc- 
tion instruction. The verification process consists 
Tt xe«t in a stage of initializing the type staCc and 
the table of register types representing the state of 
the virtual n^chine at the start of the execution of 
the tenporarily stored object coda and in a eucceasion 
of stages of verification, instruction by instruction 
,t the existence, for each current instruction, of a 
target, branching-instruction target, target of ^ «- 
cepLon handler, and in a verification and an ^ting 
of the effect of the current instruction on the type 
Ley. and on the table of register types. Xn the ev»t 
Of an unsuccessful verificati«. of the object code, the 
protocol which is the subject, of the invention consists 
in deleting the «>mentarily recorded program frag.«nt, 
„hen omitting to record the latter in the directory of 
available program fragments, and in sending an error 

code to the reader. ^ 

. The method of verifying a program fragment down- 
loaded onto an on-board system, which is the .uW*=t of 
U.e invention, applies especially to a microprocessor 
card equipped with a rewritable memory. -The .^ogram 
£rag.»nt consists of an object code and includes at 
tragjws^ inatructionB , exeeu- 

least one subprogram, a series of instructi 
least o ^ « on-board system by 

table by the microproceesor o£ tne 
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^ ,f a virtual machine equipped with an execution 
. =*-^,rtians, and malcing it possible to int rpr 

It U noteworthy in that, *ollo»ing tha a«tao- 
„I a downloading =o««nd an* th. storage o£ ^a 
^"ect coda constituting the program trag^t xn t^ 
^Itahle ™an»ry. it consists, for each s.l=program. ^ 
cluing out a stage of initializing th. type stack ^ 
tTta^le Of register t«es ^ data --^"^^ 
,tate of the virtual ^ohine at the start o£ the eK.cu 
t^I of the t^^raril. stored oh^ect code, in carrv^g 
1 a verification of the temporarily stored obae^t 
„de instruction by instruction, by discerning the 
Tslce. for each current instruction, of a hrenchi^- 
:^c ion target, of a target of » ' -^^^^-'T^^ 
oall or of a target of a sul^outine call. »>d ^ carry- 
ing out a verification and an updating of the effect of 
Z Ixent instruction on the data types "'-^^ 
Ick and of the table of register tipes. on the ba«.s 
It the eristence of a bran<*ing-instruction target, of 
a target subroutine call or of a target of an axcep- 

:.on-Ldler call ---^ ^ Jdl^ feft Te 

the table of register types is not moci 
course of a verification of all the instructions, the 
Terification process being carried out instruction by 

fv,c i-able of register types is sta- 
instruction until the table ox reg 

ble, with no modification present . Otherwxse the veri 
ficltion process is interrupted. 

The method of transforming an ob:,ect code of a 
program fragment into a standardized object code for 
thifsame program fragment, which is the s^.ect of ^e 
present invention, applie. to an object code of a pro- 

V ^hirh the operands of each instruction 
gram fragment in which the opexa»w» 

^long to the data types .^pulated by this instruc- 
t on, the execution stack does not e=^bit overflow 
^en»»no. and. for each branching instruction, the 
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t„e of the variables of the .t«k at this braachins 
Te sa». as at the targets of this branching. ^ Btan- 
aaraized *Ject code obtained is such that the oparaMs 
ot each instruction beXoug to the data t«. a manipu- 
lated this instruction, th execution staclc does not 
e^d^bit any overflow phenomenon and the execution stack 
is eTO.ty at each branching-target instruction. 

It is noteworthy In that it consists, for all 

« nh-iorf code, in annotating each 
the instructions of the obDect coae, 

«„ent instruction with the data type of the execution 
,tack before and after the execution of this instruc- 
tion, the annotation data being calculated by means of 
an analysis of the date stream relating to this in- 
struction, in detecting, within the Instructions and 
^thin each current instruction, the existence of 
branchings for which the execution stack is not empty, 
the detection operation being carried out on the tesis 
of the annotation data of the type of stack variables 
allocated to each current Instruction, m the presence 
of a detection of a non-enpty execution stack, it fur- 
ther consists in inserting instructions to transfw: 
stack variables on either side of these branchings or 
of these branching targets in order to eirpty the con- 
tents of the execution stack into temporary registers 
before this branching and to reestablish the execution 
stack from the temporary registers after this branch- 
ing, end in not inserting aw transfer instruction oth- 

erwise. . 

This method thus makes it possible to obtain a 

standardized object code for this same program frag- 

^t, in which the execution stack is empty at each 

branching instruction and branching- target instruction, 

in the absence of any modification to the execution of 

the program fragment. 

The method of transforming an object code of a 
program fragment into a standardized object code for 
this same program fragment, which is the subject of the 
present invention, applies, moreover, to an object code 
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of a prograni fragm^t in which the operands of each in- 
'.Action .elong to th data type. «..ipulated ^ this 
rt-ction, and a ope.«.d of given t^e ^it.^ into a 
..aister by an instruction of this object code as re 
register by instruction of 

read from this same register uy 

Zs oWect code with the Ba^ «iven data type The 
Tt^aaraUed object ccae . stained Is ^ 
erands belong to the data types :«nip.lated by this xn- 
:^«io.. one »d the sa^e data type being allocated 
to the s^e register throughout the standardized object 

""^^ It is notewortl^ in that it consists, for all 

instructions of the object code, in 
™rr«at instruction with the data type of the regxsters 
betore and after the execution of this instruction, the 
.notation data being calculated by of analy- 

eis of the data stream relating to this instruction, 
and in carrying out a reallocation of the original reg- 
isters e^loyed with different types, by dividing these 
o^ginal register, into separate ^^^^'^l' 

on. st»>dardi«d register is allocated to each 
data type used. Reupdatin, of the instructions which 
^pulate the operands which use the standardired reg- 

isters is carried out. 

Ihe protocol for namaging a program fragixent, 
the n«thod of verifying a program fragment, the aethods 
of transforming object code of program fragm«.ts into 
etandardized object code and the corresponding syst»s, 
which are the subjects of the preset i^tn.on. find 
an application in the development of r««ogrammable on- 
board systems, such as microprocessor cards, especially 
in the Java envirotutient . 

They will be better understood on reading the 
description and on perusing the drawings below. In 
i which, other than figures la and lb relating to th 
prior art: 
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- Figure 2 represents a flow chart illustrat- 
ing the protocol for managing a prograza frag^nent down- 
loaded onto a r^rograxro^hle on-board system 

. Figure 3a represents, by way of xllustra 
tion, a flow Chart of a method of verifying, a dom- 

^^"^ ' ^ „^ accordance with the subject 

loaded program fragment m accoraai 

of the present .invention, 

- Figure 3b represents a diagr™ illustrating 
.ata types ^ sub-tvping relatioosbipe i^lemented by 
,he ^tbod of nanagl^ and the method of verify»g a 
downloaded program fraflne»t, which is the suh.ect of 

the present invention, 

. Figure 3c represents a detail of the verxfx- 
cation method as claimed in figure 3a, relating to the 
managing of a branchi^ instruction, 

- Figure 3d represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of a suhroutine-call instruction, 

- Figure 3e represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of an exception-handler target,. 

- Figure 3f represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of a target of incoi.?>atible branchings, 

- Figure 3g represents a detail of the verifi- 
cation method as clad^ed in figure 3a, relating to the 
managing of an absence of branching target, 

- Figure 3h represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of the effect of the current instruction on 

the type stack, 

- Figure 3i represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of an. instruction for reading a register, 

- Figur 3j represents a detail of the verifi- 
cation method as claim d in figure 3a, relating to the 
.managing of an instruction for writing to a register. 
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. Figure la rwreeenCB a 4lo« <=h"^t 
i„g a method of transfor^inj, object coda of a pro- 
fragment into a standardUad object code, for this 
^ ' -"X*^^ instruction^ re- 

3 sH^tLl a brancbin^-target instruction, v.tb an 

^"*'ri^e 4b represents a flow cbart illnatrat- 
« nethod of transforming an object code of a pro- 
' frasn^nt into a standardized object code for this 
,0 ^ pro=T- regxsters a 

I^Sle. specific data type being attributed to ead. reg- 

- Figure 5a represents a detail of i.«.le««nta- 
tion of the transforation method illustrated in figure 

" . Figure 5b repres«its a detail of irolementa- 

tion of the transfoaoation »«thod illustrated in figure 

4b r 

- Figure 6 represents a functional diagram of 
20 the cos^lete architecture of a system for development 

of ^ standardized program fragment, and of a reprogram- 
^le microprocessor card allowing ii^le..entatioo of 
the protocol for managing and the method of verxfying- a 
program fragment in accordance «ith the object of the 

25 present invention. 

m general, it is indicated that the protocol 

for managing and the method of verifying and tr««f oim- 
ing a downloaded program fragment, which is the subject 
of the present invention, and the corresponding sys- 

30 t«ns. are inplemented thanks to a software architecture 
for secure downloading and execution of applets on an 
on-board data-processing syst«. with few resources, 
such as. in particular, microprocessor cards. 

in general, it is indtcat d that th description 

35 below concerns th application of the invention in the 
context of r programmable microprocessor cards of 
javaCard type, cf. documentation available el«=troni- 
cally from th company SON MIGB0Blf6««S DK.. JavaCard 
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TecWogy heading -ntiU previously i» th d.scrip- 



How«v«. th« present invention U applicable to 
on-boara system »hich is reprogrammable W dj- 

^ '4-4-Ar> -In the cod© or a 

loading an applet which xs written «x the c 

,i^tual .nachine including an execution stacX, local 
vxi uLio wKieh the execution 

variables or registers, and of wMch the 
^del is strongly typed, each instruction o* the code 
TL applet applying only to specific data types. The 
;.otocol for :«naging a program frag^t downloaded 
Lto a reprogra-able on-board system, wh«h xs th. 
subject of the present invention, will now be described 
in more detail with reference to fig- 2. 

With reference to the aWvementioned figure, xt 
indicated that tbe object code which ^ up the 
p^ogran, fragment or applet consists of a series of in- 
«^tions Which can be executed by the nacroprocessor 
of the on-board system by means of the abovementioned 
virtual machine. The- Virtual machine makes it possible 
to interpret the abovementioned object code. 

on-boerd system- is interconnected to a terminal 

via, for instance, a serial link. _ 

With reference to the abovementioned fig. 2. the 
^gement protocol which is the subject of the present 
Invention consists at least, in the on-board system, 
m detecting a command to download this program frag- 
;^t in a stag, 100a, 100b. Thus, stage 100a may con- 
sist of a stage of reading the abovementioned command 
and stage 100b of a stage of testing the command which 
has been read and verifying the existence of a down- 
loading command. ..•„^ 
on a positive response to the abovementioned 

stage 100a, 100b of detecting a downloading command, 
the protocol which is th subj ct of the present inven- 
tion subsequently consists in reading, at stage 101, 
the object cod which makes up the relevant program 
feagment. and temporarily storing the ^^^"^^ 
object code in th memory of the on-board data- 
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processing system. The abovementioned ten5,orary storing 
operation can be executed either in the rewritable mem- 
ory or, if appropriate, in the random-access memory o£ 
the on-board system, when this has sufficient capacity. 
The stage of r ading the obj ct code and ten^porarily 
storing it in the rewritable memory is designated as 
loading the code of the applet in fig. 2. 

The abovementioned stage, is then followed toy a 
stage 102 consisting in submitting the whole of the 
tercporarily stored object code to a process of verifi- 
cation, . instruction by instruction, of the abovemen- 

tioned object code- 

The verification process consists, at least in a 

stage of initializing the stack of types and the table 
of data types representing the state of the virtual ma- 
chine at the start of execution of the ten^orarily 
stored object code, and in a succession of stages of 
verifiying, instruction by instruction, by discerning 
the existence, .for each current instruction, designated 
. li, of a target such as a branching- instruction target 
designated CIB, a target of an except ion^handler call 
or a target of a subroutine call. A verification and 
update of the effect of the current instruction ij on 
the stack of types, and on the table of register types 

is carried out. 

When the verification has been successful at 
stage 103a, the protocol which is the subject of the 
present invention consists in recording, at stage 104, 
the downloaded program fragment in a directory of 
available program fragments, and in sending to the 
reader, at stage 105. a positive rec^tion acknowledg- 
ment. 

on the other hand, in the case o£ uxiBucceBsful 
verification of the object code at stage 103b. the pro- 
tocol which is the subject of the present invention 
consists in inhibiting, in a stage 103c, any execution 
on the on-board system of the momentarily recorded pro- 
gram fragment. The inhibition stage l03c can be i-ple- 
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J - a« a nonlimiting exaxr^le, this 

niented in various ways... As a tiojixxul^ 

stage can consist in deletxng, at stage 

«-.««TnoTi+- without recording 
tarily recorded program fragment, wxcnouu 

this program fragment in the dir ctory of available 
program fragments and, at stage 107, in sending an 
,or code to the reader. Stages 107 and 105 can be om- 
plemented eith^ sequentially after stages 106 and 104 
respectively, or in multitasking operation with them. ^ 

With reference to the same fig. 2, on a negative 
response to the stage consisting in detecting a down- 
loading command at stage 100b, the protocol which is 
the subject of the present invention consists in de- 
tecting, in a stage 108, a command to select an avail- 
able program fragment from a directory of program f rag- 
„^ts and, on a positive response to stage 108, having 
detected the selection of an available program frag-" 
„^t, in calling, at stage 109, this selected available 
program fragment in order to execute it. Stage 109 is 
then followed by a stage 110 of executing the called 
available program fragment by way of the virtual ma- 
chine, with no dyiiamic verification of variable types, 
rights of access to the objects which are manipulated 
by the called available program fragment, or overflow 
of the execution stack when each instruction is exe- 
euted. 

In the case where a negative response is ob- 
tained at stage 108, this stage consisting in detecting 
a command to select a called available program frag- 
ment, the protocol which is the subject of the present 
invention consists in proceeding, in a stage 111. to 
process the standard commands of the on-board system. 

Regarding the absence of dynamic verification of 
type or rights of access to objects of, for instance, 
javaCard type, it is indicated that this absence of 
V rification does not conpromise the s curity of the 
card, because the code of the applet has necessarily 
successfully passed verification. 
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More speeltically, it i« indicat«l that tl» code 
.erifiction which is carried out. as claimed in ^ 
method Which is the s>*:iect of the pres«.t ^v»tx»^ 
o„ the .nicroproceBsor card or on-hoard data-processing 
system is «ore selective than the custonary v^^fxca^ 
Uon of codes for the virtual Java machine as described 
1^ the work entitled Java Virtual Machine Specifi- 

cation- which wa^ mentioned previously in the descrip- 

However, any code of the Java virtual machine 
vhich is correct as far as the traditional Java veri- 
lier is concerned can be transformed Into an e<fiivalent 
code Which is capable of passing successfully the code 
verification v*lch is carried out on the microprocessor 
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Whereae it is possible to imagine VTriting di- 
rectly Java codes which satisfy the aboveinentioned . 
verification criteria ntentioned in the context of xm- 
plementing the protocol which is the subject of the 
present invention, a noteworthy object of the latter xs 
also the iinplementation of a method of autoinatic trana- 
foimation of any standard Java code into a standardized 
code for the same program fragment, necessarily satis- 
fying the verification criteria iitplemented as inen- 
tioned above. The method of transformation iato stan- 
dardized code, and the corresponding system, will be 
described in detail subsequently the description. 

A more detailed description of the method of 
verifying a program fragment, or applet, in accordance 
with the subject of the present invention, will now be 
given with reference to fig. 3a and the subsequent fig- 



\ires. 



in general, it is indicated that the verifica- 
tion method which is the subject of the present inven- 
tion can be inplemented either as part of the protocol 
for raging a program fragment which is the subject of 
the present invention as described above with reference 
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to fig. 2, or independently, to provide whatever veri- 
fication process is judged necessary. 

in general, it is indicated that a program frag- 
is made up of an obj ct code iticluding at least 
one subprogram, more commonly designated a n^thod. and 
is made up of a series of instructions which can be 
routed by the ndcroprocessor of the on-board system 

via the virtual machine. 

AS shown in fig. 3a, the verification method 
consists, for each subprogram, in carrying out a stage 
200 of initializing the stack of types and the table of 
register types of the virtual inachine by data repre- 
senting the state of this virtual machine at the start 
of execution of the object code which is the subject of 
verification. This object code can be stored tefl«)orar- 
ily as described above with reference to implementation 
of the protocol which i^ the subject of the present in- 
vention . 

The abovemantioned stage 200 is then followed by 
a stage 200a consisting in positioning the reading of 
the current instruction Ii,. index i, on the first in- 
struction of the object code. Stage 200a is followed by 
a stage 201 consisting in carrying out a verification 
of the abovementioned object code, instruction by in- 
struction, by discerning the existence, for each cur- 
rent instruction, designated li, of a branching- 
instruction target CIB, of a target of an exception- 
handler call, designated CEM, or of a target of a sub- 
routine call CSR. 

The verification stage 201 is followed by a 
stage 202 of verifying and updating the effect of the 
current instruction li on the data types of the stack of 
types and of the table of register types, as a function 
of the existence, for the current instruction which is 
pointed at by another instruction, of a branching- 
instruction target CIB, of a targ t of a subroutine 
call CSR or a target of an exception-handler call CBM. 
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Stage 202 for the current instruction Ii is fol- 
lowed by a stage 203 to test whether the last instruc- 
tion has been reached, the test written as: 

li = last Inattuction f the object code? 
on a negative response to test 203, the process passes 
to the next instruction 204, written i = i*l, and to 

the return to stage 201. 

It is indicated that the abovementioned verifi- 
cation, at stage 202, has been successful when the ta- 
ble of register types is not modified during verifica- 
tion of all the instructions li which make up the object 
code. For this purpose, a test 205 of the existence of. 
a stable state of the table of register types and pro- 
vided. "ChiB test is written: 

3? Stable state of table erf re^sher types, 
on a positive response to test 205, verification has 

been successful. 

on the other hand, in the case where no absence 
of modification is noticed, the verification process is 
repeated and reinitiated by returning to stage 200a. It 
is demonstrated that the process is guaranteed to end 
after a maximum of NrxH iterations, where Nr designates 
the nuitiber of registers used and H designates a con- 
stant depending on the subtyping relation. 

Various indications concerning the types of 
variables which are manipulated in the course of the 
verification process described above with reference to 
fig. 3a will now be given with reference to fig. 3b. 

The abovementioned variable types include at 
least class identifiers corresponding to object classes 
which are defined in the program fragment which is sub- 
jected to verificaticai, numeric variable types • includ- 
ing at least a type short, an integer coded on p bits, 
where the value of p can be 16, and a type for the re- 
turn address of a jun5> instruction JSR, this address 
type being identified as retaddr , a type nuU r lating 
to r ferences of null objects, a type object r lating 
to obj cts proper, a specific type 4 representing the 
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intersection of all the types and corresponding to the 
value zero nsl- r specific type T representing 

the ^on of all the typ s and corresponding to any 

tvpe of values. , ^ 

With reference to fig. 3b, it is indicated that 
all the abovementioned variable types verify a subtyp- 
ing relation: 

object e t; 

short. retaddr sT; 

Is aull . short , retaddr 

A more specific exanple of a process of verifi- 
cation as illustrated in fig. 3a will now te given, 
with reference to a first ex««ple of a data structure, 
which is shown in table Tl in the annex. 

The abovementioned exanple concerns an applet 

■written in Java code. 

The verification process accesses the code of 
the subprogram which forms the applet which is sub- 
jected to verification via a pointer to instruction li 

which is being verified. 

The verification process records the size and 
type of the execution stack at the current instruction 
li corresponding to saload in the exai^ple of the above- 
mentioned Table Tl. 

The verification process then records the si;se 
and type of the execution stack at the current instruc- 
tion in the stack of types via its type stack pointer. 

AS mentioned above in the description, this 
stack of types reflects the state of the execution 
stack of the virtual machine at the current instruction 
li. in the exans^le shown in table Tl, at the time of the 
future execution of . instruction li, the stack will con- 
tain three entri s: a reference to an object of class 
C, a reference to a table of Integers coded on p = 16 
bits, the type short [3, and an integer of P = 16 bits 
of type short. This is also shown in the type stack, 
whicl. also contains three entries: C, the type of 6b- 
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jeca of =la.s C. shsrtll. the type of tables of int.- 
Us P ■ 16 5?!2£t. °* ° ' 

Another noteworthy tota structure consists of a 
tal,le of register types, this table reflecting the 
3tate of the registers, that is to say of the regist^s 
Which store the local variahles, of the virtual 

chine- ^_ . . 

continuing the «ca^le indicated in table Tl, 

is indicated that entry 0 of the table of register 
^es contains type C, i.e. at the time of the future 
execution of the current instruction I. = saload, regis- 
ter 0 is guaranteed to contain a reference to an object 

of class C. ^ - . 

various types which are manipulated durxng 

verification and stored in the table of register types 
and in the type stack are represented in fig. 3b. These 

types include: 

class identifiers CB corresponding to specxfxc 
object classes which are defined in the applet; 
base types, such as short , an integer coded on 
p = 16 bits, intl and int2, the most and least 
significant p bits respectively of integers 
coded on, e.g., 2p bitB, or retaddr, the return 
address of an instruction as mentioned above ; 
the type null, representing the references of 
null objects. 

Regarding the subtyping relation, it is indi- 
cated that a type Tl is a subtype of a type T2 if every 
valid value of type Tl is also a valid value of type 
T2. The subtyping between class identifier reflects the 
inheritance hierarchy between classes of the applet. On 
the other types, subtyping is defined by the lattice 
Shown in fig. 3b, where i is a subtype of all types and 
all types are subtypes of T. 
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The sequence of the process af verifying a sub- 
prograzu which fox^ an applet is as follows, referring 
to the abovementioned table Tl. 

Th verification process is carried out inde- 
pendently on each subprogram of tbe appl t. For each 
subprogram, the process carries out one or more verxfx- 
cation passes on the instructions of the relevant, sub- 
program, o^he pseudocode of the verification process is 
given in table T2 in the annex. 

The process of verifying a subprogram begxns 
with initializing the type stack and the table of reg^ 
ister types shown in table Tl, this initialization re- 
flecting the state of the virtual machine at the start 
of execution of the subprogram being examined. 

The type stack is initially eits>ty, the stack 
pointer equals ^ero, and the register types are ini- 
tialized with the types of the parameters of the sub- 
program, illustrating the fact that the virtual machine 
passes the parameters of this subprogram in these reg- 
isters. The register types which are allocated by the 
subprogram are initialized to data types. J,, illustrat- 
ing the fact that the virtual machine initializes these 
registers to zero at the start of execution of the sub- 
program. 

Next, one or more verification passes on the in- 
structions and on each current instruction Ii of the 
subprogram are carried out. 

At the end of the implemented verification pass, 
or of a succession of passes for instance, the verifi- 
cation process determines whether the register types 
contained in the table of register types shown in table 
Tl of the annex have changed during the verification 
pass, in the absence of change, verification is termi- 
nated and a success code is returned to the main pro- 
gram, which mak s it possible to send the positive re- 
. ception acknowledgment at stage 105 of the management 
protocol shown in fig. 2. 
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l£ a cJxange to th« abovexoentioned table o£ reg- 
ister types is present, the verification proc ss r - 
: rt: t" verification pa., until t.e regi.^^ tVP.. 
Contained in the table of register typee stable, 
.ontained .n^ ^ence proper of a verification p... wMcb 
,s carried out one or «cre ti^. until the table of 

. « -5., Stable will now be described with 
register types is etaoxe wixa 

reference to figs. 3c to 3 j . ^ 

Por each current instruction li, the following 

verifications are carried out: 

With reference to fig- 3a at stage 201, the 
verification process detemdnes whether tlxe current in- 
struction I. is the target of a branching instruction, a 
subroutine call or an exertion-handler call, as n^- 
tioned above, .^e verification is carried out by ex^- 
ining the branching instructions in the code of the 
subprogram and the- exception handlers associated with 

this subprogram. 

Mitt re£er«^e to flB- 3c which begins «xth 
Bt»fl« 201, when the current instrvcticn 1. is the t^oet 
of a branching instruction, this condition being inple- 
mmited by a test 300 flesisnated by li = CIB, this 
branchins beins unconditional or conditional, the veri- 
fication process checks that the type stack is en«.ty at 
this point of the subprogr^t, tar a test 301. On a posi- 
tive response to the test 301, the verification process 
is continued by a contert continuation stage narked 
continue A. On a negative response to the test 301, the 
type stack not being enpty. the verification fails and 
the applet is rejected. This failure is represented by 

the Failure stage. . . 

With reference to fig. 3d which begins with the 
continue A stage, when the current instruction I, is the 
target of a subroutine call, this condition being ii.- 
plen«nted by a test 304 I. = CSE, the verification proc- 
ess verifies. In a test 305. that the previous instruc- 
tion I.-, does not continue in se,^enc . This verifxca- 
til is l^le«e„tea by a test stage 305 when the pr«vi- 
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rwtine return or a raising 

at stage 305 is marked as follows: , . „ r 

I.. - IB^ona..w, return RSK or ra.sxng L- 

on a negative response to test 305, t^e verifi- 

Vson T^rocess fails in a Failure stage. On the other 
cation process lax verifica- 
hatid on a positive response to test juo, 
T^^r^Js r.l.itiaU.e. the tvpe «tacK i« a ^ 

1. II. -taiHB exactxy on. an«y of retagdr tvpe ^ 
.etum address of the abov««ntioned s^rc.t.ne. i£ the 
Lrrent instx^tio. I. at stage 304 is not the target of 
a .„l„»uti»e call, .he verification. Prcceae c»ti.- 
ued in the context at the continue B atage. 

With reference to fig- 3e. -hen the current in- 
struction U is the target of ««eption handler, thxa 
ccouiition being i^ple-aented hy a test 307 -narked li = 
cm. Where cm designatea the target of a« 
ha^er, this condition is i-^lemented by a test 307, 

. jnarked: 

li = CEM. 

on a positive response to test 307. the P--"' J*^; 
flee that the previous instruction is an unconditional 
branching, a subroutine return or a raising of ex=«.- 
tions by a test 305, marked: 

X,., = IB,»^ti<«ia, return RSR or raising L- 

EXCEPT 

' on a positive response to test 305, tHe verifi- 
cation process proceeds to reupdate the type stack, at 
a stage 308, by entering exception types, aarked EXCEPT 
type, stage 308 being followed by a context continua- 
tion stage, continue c. On a negative response to test 
305, the verification process fails by the stage marked 
Failure. The program fragment is then rej cted. 

,rtth reference to fig. 3£, whan the current in- 
struction I. is the target of multiple inco«^tlble 
: branchings, this condition is in,>le«ented by a t st 
309, which is marked: 
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li B incoinpatible XIBs 
inco^tiWe bremehingB being, for inst»>c . an uncon- 

Lent exception h^dlers. On a positive response to 
test 309. the branchings being inco«patible, the vern- 
ation process fails b. a stage ™arHed Failure ^ 
the program fragment is rejected. On — ^^^^ ^1 
sponse to test 309, the verification process " 
ued by a stage continue P. Test 309 begxns wi^ 

the continue C stage »hich was «»ntioned previously in 

the description. 

With reference to fig. 3g, when the current in- 
struction I. is not the target of any branching, this 
condition being iH^^leroaxxted by a test 310 beginna^g 
15 with the abovementioned continue this test bei^g 

jnarlced 

li a? branching targets, 
where 3 designates the existence symbol, 
the verification proceee continues on a negative re- 
20 sponse to the test 310 by passing to an update of the 
type stack at stage 311, stage 311 and the positive re- 
sponse to test 310 being followed by a context con- 
tinuation stage at stage 202. which is described above 
in the description with reference to fig. 3a. 
2s A more detailed description of the stage of 

verifying the" effect of the current instruction on the 
type stack at the abovementioned stage 202 will now be 
given with reference to fig. 3h. 

According to the abovementioned figure, this 
30 stage can include at least one stage 400 o£ verifica- 
tion that, the type execution stack includes at least as 
n«ny antries as the current instruction includes oper- 
ands. This test stage 400 is marked: 
Ijbep NOpi 

35 wher iJbep designates the number of entries of the type 
stack and NOpi designates the number of operands in- 
cluded in the current instruction. 



no 01/1*958 - - 

0„ a positive response to test «0. this test is 
followed by a stage «la o£ ,»Bta=3cin8 the t«.e sta*, 
Z .0^ the t^s o* the entries ^t 

"a top o£ the stack are subtypes of the types of the 
o!LenL of the ahovementioned arrant in3tructic». « 
rsHfae 401a. the operand types of the instruction x 
"reMnea ^i. and the types of the entries at the 
top of the stack are norked Targs. ^ ^„ , 

At stage 401b, the vexificotion corresponda to a 
verifioetlou o£ the subtypl-g relation Targs subtype of 

on a negative response to testa 400 and 
the verification process fails, «bich is abo«n by ac- 
cess to the Failure stage, on the other hand, on a 

401b the verification proc- 
positive response to test 40i©, cue 

aBB ie continued, and consists in carrying ont: 

- A stage of verifying the existence of a suffi- 
cient in^ttory space on the type stack to proceed to 
stack the results of the current instruction. Thxs 
verification stage is i««>le««nted by a test 402, 
marked: 

Stack- space ^ Results-space 
where . each side of the inequality designates the corre- 

sponding msnory space. 

.on a negative response to test 402, the verxfi- 
cation- process fails, which is shovm by the Failure 
stage. On the other hand, on a positive response to 
test 402, the verification process then proceeds to 
stack the data type^ which are assigned to the results 
in a stage 403, the stacking being done on the stack of 
data types which aye- assigned to these results. 

AS a nonlimiting example, it . is indicated that 
to implement fig. 3h for verifying the effect of the 
current instruction on the type stack, for a cuxrent 
. instruction consisting of a Java saload instruction 
corresponding to reading an integer element coded on p 
- 16 bits in a table of integers, this table of inte- 
gers being defined by the table of integers and an x.- 
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teger index in this ta»=le. and the .e«ult ^ the inte- 
Ter vhich is read at thi. index in this ta^le ^ 
Lification process checks that the typ stack con- 
vexii-j-v- lenieats that the two eleroents at 

^Lt Lpectivexy. proceeds to the unstacking process 
Slhen to the process o£ stacking the data type short 

OS the result type. ^.^ 

Additionally, with reference to fig. 3x. to m- 
10 Pl'ement the stage of verifying the effect of the cur- 
io piem«* -tack when the current 

rent instruction on the type stacic, wnen 

instruction li is a read instruction, marked IR, of a 
register of address n, this condition being implemented 
by a test 404 mrked I. = ^. on a positive response to 
15 the abovementioned test 404, the verification process 
consists in verifying the data type o£ the result of 
this reading, in a stage 405. by reading the entry n in 
the table of register types, then in detemdnizig the 
effect of the current instruction li on the type stack 
20 by an operation 406a of unstacking the entries of the 
stack corresponding to the operands of this current xn« 
struction and by stacking 406b the data type of this 
result- The operands of the instruction H are inarked 
OPi Stages 406a and 406b are followed by a return to 
25 the context continuation, continue F, On a negative re- 
sponse to test 404, the verification process .is contin- 
ued iv the context continuation, continue F. 

With reference to fig. 3j, when the current in- 
struction li is a write instruction, marked IW, ' of a 
30 register of address n, this condition being ii^lemented 
by a test marked li = on a positive response to 

test 407, the verification process consists in deter- 
xrdning, in a stage 408. the effect of the current in- 
struction on the type stack and the type t of the oper- 
35 and which is written in the register of address n 
then, in a stag 409, in replacing the typ entry of 
the table of register types at address n by the type 
diately above the previously stored type and above 
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the type t of the operand ^ich Is «rittea in. the rag- 
TtJlt address n. Stage 409 is foUowed hy a r turn 
to the context continuation, continue 204. On a nega- 
tive response to test 407, the verification procee. « 
continued by a context continuation, continue 204 

AS an example, when the current instruction U 
corresponds to writing a value of type D into a regis- 
ter of address 1, and the type of register 1 before 
verification of the instruction was c, the type of reg- 
ister 1 is replaced hy the type *dect, v*ich is the 
sHBllest type which is higher than c and D in the lat- 
tice of types shovm in fig- 3b. 

in the s«ne way, as an exaii«,le, «ben the current 
instruction I. is a read of an instruction aload-0 con- 
siBtiiag in staclcing the contents of register 0, and en- 
try 0 of the table of register types is C, the verifier 
stacks C onto the type stack. 

A» exaitiple of verifying a subprogram written xn 
a Java environment will now be given, with reference to 
tables T3.and T4 in the annex. 

Table T3 represents a specific JavaCard code 
corresponding to the Java subprogram which is included 

in this table. 

table T4 shows the contents of the table of reg- 
ister types and of the type stack before verification 
of each instruction. The type constraints on the oper- 
ands of the various instructions ^e all observed. -Che 
stack is B^ty both after the instruction 5 to branch 
to instruction 9, symbolized by the arrow, and before 
the abovementioned branching target 9. The type of reg- 
ister i; which was initially ±, becomes null, the upper 
bound of SSll i ' instruction 1 to store a 

value of type null in register 1 is examined, then be- 
comes of type short [1, the upper bound of types short [] 
and null, when instruction 8 to store a valu of type 
short[] in register 1 is processed. The type of regis- 
T7"l living changed during the first verification 
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p,,., a «cond is oarri^ out. distributing raais- 

This second veritication paas is successful, just l»Xe 
L £i«t, and does not change the register types. The 
verification process thus terminates successfully. 

various exai^les of cases of failure of the 
verification process on four e««i.les of incorrect code 
will now b. given with reference to table T5 in the an- 



nex: 
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L5 



20 



At point a) of table T5, tlxe purpose of the code 
given as an exaitole is to attettpt to fabricate 
an invalid object reference using an arithmetic 
process on pointers. It is rejected by verifica- 
. tion of the types of arg^ents of instruction 2 
sadd, which requires these two arguments to be 
of type short. 

At points b) and c) of table T5. the purpose of 
the code is to carry out two attenpts to trans- 
form any integer into an object reference. At 
point b) , register 0 is ^sed simultaneously with 
type short, instruction 0. and with type null, 
instruction 5. Consequently, the verification 
process assigns type T to record 0, and detects 
a type error when register 0 is returned as a 
25 result of type ob ject at instruction 7 . 

At point c) of table T5, a set of branchings of 

1. ■ is used to leave 

type "if ... then . . . else ... is usw 

^t the top of the stack a result which consists 
of either an integer or an object reference- The 
30 verification process rejects this code because 

it detects that the stack is not enpty at the 
branching from instruction 5 to instruction 9. 
synibolized by the arrow. 

Finally, at point d) of table 5, the code con- 
35 tains a loop which, at each iteration, has the 

effect of stacking an additional integer on the 
top of the stack, and thus causing a stack over- 
flow after a certain number of iterations. The 
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V rification process r jects this code, noticing 
that the stack is not enpty at the backward 
branching from instruction 8 to instruction 0, 
symbolized by the return arrow, the stack not 
5 being en©ty at a branching point. 

Ttoe various exaii?)les given above with reference 
to tables T3, T4 and T5 show that the verification 
process, which is the subject of the present invention, 
is particularly efficient, and that it applies to ap- 
10 plets, and in particular to subprograms thereof for 
which the conditions of stack type, or . respectively of 
the enpty character of the type stack previously, and 
to the branching instructions or branching targets, are 

satisfied. . 
15 Obviously, such a verification process xitS)lxes 

writing object codes which satisfy these criteria, 
these object codes possibly corresponding to the sub- 
program in the abovementioned table T3 . 

However, and in order to ensure verification of 
20 existing applets and subprograms of applets which do 
not necessarily satisfy the verification criteria of 
the method which is tbe subject of the present inven- 
tion, in particular regarding applets and subprograms 
which are written in the Java environment, the purpose 
25 of the present invention is to establish methods of 
transforming these applets or subprograms into stan- 
dardized applets or program fragments, making it possi- 
ble to undergo successfully the verification tests of 
the verification method which is the subject of the 
30 present invention and of the management protocol which 
iitplements such a method - 

For this purpose, the subject of the invention 
is the i«©lementation of -a- method and a program for 
transforming a traditional object code forming an ap- 
35 plet, it being possible to inclement this method and 
this transformation program, outsid an on-board system 
or microproc asor card, when the relevant appl t is 
created . 
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The n»thod of, transforidos, code Into etand^rd- 
i«d code. Which is the subject of the present inven- 
tion, will now b« ^ " framework of the 
aava e»vironn>ent. as a purely illustrative «a«,le 

The JVH codes :Aich are produced by existing 
aava cc^ilers satisfy various criteria, which are 
stated below! 

CI. the argun^nts of each instruction actually be- 
long to the types which this instruction «c- 

•LQ pects; 

C2 • the stack does not overflow; • 

C.3. for each branching instruction, the type of the 
stack at this branching is the saine as at the 
possible targets for this branching; 
,5 C'4- a value of type t which is written into a regis- 
ter at one point of the code and reread from the 
same register at another point of the code is 
always reread with the same type t; 
The iit^jlementation of the verification method 
20 which is the subject of the present invention in^plies 

that criteria C'3 and C'4, which are verified by the 

object code which is submitted for verification, be re 

placed by criteria C3 and C4 below: 

C3: the stack is enpty at each branching instruction 

25 and at each branching target; 

C4: the same register is used with one and the saiae 
type throughout the code of a siibprograin. 
With reference to the abovementioned criteria, 
it is indicated that Java compilers guarantee only the 

30 weaker criteria C'3 and The verification process 

which is the subject of the present invention and the 
corresponding management protocol in fact guarantee 
nu>re restrictive criteria C3 and C4, making it possible 
to ensure the security of execution and management of 

35 applets. 

The concept of standardization, covering the 
transformation of codes into standardized cod s, can 
present various aspects, to the extent that replacement 
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of criteria 0^3 and CM by criteria C3 and C4, in con- 
fonrity with th. verification proc«6 which is th sub- 
ject of the present invention, can be implemented ind - 
pendently. to ensure that the stacK is e^ty at each 
Lanchlng Instruction and at each branching tar«et^»d 
respectively that the registers »hich the av^let ^ens 
are typed, and a sinale data type which is assxgned for 
^.ion of the relevant applet corresponds, to ea^ 
open register, or, on the other hand, " 
isfy the .*ole of the verification process which is the 
subject of the present invention. 

The i»ethoa of transforming an object code xnto 
standardized object code as claimed In the invention 
«ill consequently be described a. claimed in two dis- 
tinct l^len«ntation modea, a first l^lementation mode 
corresponding to transforation of an object code which 
Batlsfies criteria CI, C2, C-3. C'4 into a standardl;=ed 
object code which satisfies criteria Cl, C2, C3, C-4 
corresponding to a standardized code with an e.*ty 
branching instruction or branching target, then, a. 
claiined in a second implementation mode, in which the 
traditional object code which satisfies the sai»e ini- 
tial criteria is transformed into a standardised object 
code .*ich satisfies criteria Cl, C2, C-3, C4, for in- 
stance corresponding to a standardized code using typed 



registers. 

The first ifltplementation mode o£ the code trans- 
fornetion nusthod which is the subject of the present 
invention will now be described with reference to fig. 
4a. in the implementation mode which is shown in fxg. 
4a the initial traditional code is considered to sat- 
isfy criteria Cl+C2+C'3. and the standardized code 
which., is .obtained as the result of the transformation 
is considered to satisfy criteria C1+C2+C3. 

According to the abovementioned figure, the 
transformation method consists, for each current in- 
struction I. of the code or of th et*program, in anno- 
tating each instruction, in a stage 500, with the data 
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^ype of the stack b^ior^ and a£t^ execution of thi« 
irtruction. o^e annotation data is xoark d AX. and X3 
: lated ^ the .elation 1.^.1. t.e .e^e.an^ 

current instruction. The annotation data i3 calculated 
:r-ane of an analysis of the . data strea. relatxn. to 
instruction. The data types hefore and after exe- 
cution of the instruction are marked tbe. and tae. re- 
spectively- calculation of annotation data by analysis 
data strea. is a traditional calculation which 
is known to tho.e skilled in the art. and will there- 
fore not be described in detail . 

The operation which is inplemented at stage 500 
is illustrated in table T6 in the annex, in which, for 
an applet or subprogram of an applet including 12 in- 
structions, the annotation data AI. made up of the types 
of registers and the types of the stack are introduced^ 
mie abovementioned stage 500 is then followed by 
a stage 500a consisting in positioning the index i on 
the first instruction li ^ Ix- Stage 500a is followed by 
a stage 501 consisting in detecting, among the instruc- 
tions and in eadh current instruction I., the existence 
. of branchings marked IB or of branching targets CIB for 
which the execution stack is not en5>ty. This detection 
501 is implemented . by a test which is carried out on 
the basis of the annotation data Al^ of the type of 
stack variables allocated to each current instniction, 
the test being marked for the current instruction: 
li is an IB or CIB and stack (AI) ? empty, 
on a positive response to test 501, i.e. in the 
presence of detection of a non-«.5>ty execution stack, 
the abovementioned test is followed by a stage consist- 
ing in inserting instructibns to transfer stack vari- 
ables on either side of these branchings IB or branch- 
ing targets CIB, in order to eo^^ty the content of the 
execution stack into tetqporary registers before thxs 
branching and to reestablish the execution stack from 
the ten^orary registers after this branching. The in- 
sert ion stage is narked 502 in fig. 4a. It xs followed 
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by a stage 503 to test reaching the last instruction, 
marlced 

It = last instruction? 
on a negative response to the test 503, an increment 
504 i=i+l is carried out, to go on to the next instruc- 
tion and return to stage 501. On a positive response to 
test 503, an End stage is initiated. On a negative re- 
sponse to test 501, the transformation method is con- 
tinued by a branching to stage 503 in the absence of 
insertion of a transfer instruction, iniplementation of 
the method of transfortciing a traditional code into a 
standardized code with branching instruction with empty 
stack as represented in fig. 4a makes it possible to 
obtain a standardized object code for the same initial 
prograia fragment in which the stack of stack variables 
is einpty at each branching instruction and each branch- 
ing-target instruction, in the absence of any modifica- 
tion to the execution, of the program fragment. In the 
case of a Java environment, the instructions to trans- 
fer data between stack and register are the load and 
store Instructions of the Java virtual machine. 

Returning to the exaatple introduced in table T6, 
the transformation method detects a branching target 
where the stack is not enoty at instruction 9. The 
.. method is then to insert an instruction istorej, before 
the branching instruction 5 which leads to the above- 
mentioned instruction 9, in order to save the content 
of the stack in register 1 and ensure that the stack is 
empty at the time of the branching. Symmetrically, an 
instruction iload 1 is inserted before the instruction 
target 9, to reestablish the content of the stack ex- 
actly as it was before the branching. Finally, an in- 
struction ietore 1 is inserted after instruction 8 to 
ensure that the stack is balanced on the two paths 
which lead to instruction 9. The result of th trans- 
formation carried out in this way into a standardized 
code is shown in table T7. 
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one second irrt.lBnentati<« mode o£ the tranrfor- 
^tic in^chod which is th subject of the preset in- 
vention will now be described with reference to fig. 4b 
the c.se in which the initial traditionel oM ot 
code satisfies criteria and the standardized ob- 

ject code satisfies criteria C1+C4. 

With reference to the abowementioned fig. 4b, it 
is indicated that the method, in this i„pl«nentatian 
consists in annotating, as claii«d in a stage 500 
which is approximately the sane as that which is shown 
in fig 4a, each current instruction li with the type of 
register data before and after execution of this in- 
struction, in the same way. the annotation data All " 
calculated by means of an analysis of the data stream 
relating to this instruction. 

The annotation stage 500 is then followed by a 
stage consisting in carrying out a reallocation of the 
regist^, the stage mrXed 601, by detecting the 
original registers en5,loyed with • different types, by 
dividing these original registers into separate stan- 
dardized registers, one standardized, register being al- 
located to each data type used. Stage 601 is follo«red 
a stage 602 of reupdating the instructions which «na- 
nipulate the operands which use the abovementioned 
standardized registers. Stage 602 is followed by a con- 
text continuation stage 302. 

With reference to the example given in table T6, 
it is indicated that the transformation method detects 
that the register of rank 0, marked rO, is used with 
the two types, object, instructions 0 and 1, and int, 
instruction 9 and following. The method is then to di> 
vide the original register rO into two registers, reg- 
iBter 0 for the use o£ object types and register 1 for 
us s of int typ . Referenc s to record 0 of int type 
are thea rewritten by transforming them into references 
to record 1, the standardised code obtained being shown 
in table T8 in the annex. 
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It is noted, in a nonlimitinff . way/ that in th 
^e^^e which is introduced with reference to the 
^vercentioned tabl. T8, the new register 1 is used si- 
..Itaneously for standardization of the staclc and for 
creation of typed registers by dividing of regx.ter 0 

into two registers. 

The ««thod of tr^iaforming a traditional code 
into a .tandaraized code with branching instruction 
with e^ty stack as described in fis- 
described in n»re detail in a preferred, nonlx«dting 
implementation mode, in relation to fiS- 5a. 

This ij»plementation mode concerns stage 501, 
consisting in detecting, within the instructions and 
within each current instruction li, the existence of 
branching IB, or respectively of branching target CIB. 
for which the stack is not empty. 

Following the detenainatian of target instruc- 
tions ^ere the stack is not empty, this condition be- 
ing narked at stage 504a, Ii stack#e«pty, the transfor- 
,„ation process consists in associating with these ^- 
stiuctions, at the ebovementioned stage S04., a set of 
new registers, one par ' stack location which is active 
at these instructions. Thus, if i designates the rank 
of a branching target of ^ich the associated stack 
type is not enpty and is of type tpli to tpn. with n > 
0 stack not eni.ty, the transfon«tion process allo- 
cates n new, as yet unused, registers, r> to r., and as- 
sociates them with the corresponding instruction 1. 
This operation is iinplemented at stage 504a. 

Stage 504a is followed by a stage 504 consisting 
in examining each detected instruction of rank i and 
identifying, in a test stage 504. the existence of a 
branching target CIB or of a branching IB. Stage 504 is 
shown in the form of a test designated by: 
5?CIB,IBandIi=ciB. 

in the case that the instruction of rank i is a 
branching target CM represented by the preceding 
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eouality, and that tl^e! stack of stetck variables at this 

. . *.««^i.i7 i e with a positive response 

instruction as not eir^pty, i.e. wicn f 

to test 504, for every preceding instruction of rank 
i.l consisting of a branching, a raising of an exc^ 
tion or a prograia return, this condition is ii«ple»^ted 
at test stage 505, designated by: 

= IB, EXCEPT raising, Prog, return. 
The detected instruction of rank i is only accessible 
by a branching. On a positive response to the aboveznen^ 
tioned test 505, the transforroation process consists xn 
carrying out a stage 506 consisting in inserting a set 
of load instructions of load type from the set of ne« 
regist:ers before the relevant detected instruotion of 
rank i. The insertion operation 506 is followed by a 
redirection 507 of all branchings to the detected in- 
struction of rank i, to the first inserted load on^ 
struction load, ihe insertion and redirection opera- 
tions are shown in table T9 in the annex. 

For every preceding instruction of rank i-l con- 
tinuing in sequence, i.e. when the current instruction 
of rank i is accessible siitrultaneously by a branching 
and from the preceding instruction, this condition be- 
i^g i„plemented by test 508 and syntoolized by the rela- 
tions : 

and 

IB^Ii 

the transformation process consists in a stage 509 of 
inserting a set of backup instructions store to back up 
to the set of new registers before the detected in- 
struction of rank i, and a set of load instructions 
load to load from this set of new registers. Stage 509 
inhen followed by a stage 510 of redirection of all 
the branchings to the detect d instruction of rank a. to 
the first inserted load instruction load. 

m the case that the detected instruction of 
rank i is a branching to a determined instruction, for 
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3^ .detected instruction r»k i ««i»tin, of - 
Zmti^ branching, this condition be^ in^l«^ted 
by a. test 511 marked: 

trsnsfor^ation proc »ow» in flQ- consists 

2 inserting at a stage 5i2. on a positive response to 
tesr^ll, before the detected instruction of r«* i. 

^. „ The transformation 

n-ltiple backup instructions store. Tbe 

process inserts before the instruction . '^^IT 
tions store as shown in table Til as an exar»ple. The 
in«tra=";i^s store address registers r. to r. vhere n 

* ^-=./^< Bi-eire Thus the backup xn- 
designates the number o£ registers. 

struetion is associated with each new register. 

For every detected instruction of rank i con- 
sisting of a conditional branching, and for a number 
Z, greater than 0, of operands n«nipulated by thxs- 
c^^ditional branching instruction, this condition bexng 
litplemented by the test 513 marked: 

IiaIBc(»dit. 

with mOp > 0 

the tr^sformation process, in positive response to the 
abovementioned test 513, consists of inserting, at a 
stage 514 before this detected instruction of ^a-k x, a 
pemutation instruction marked swap.^ at the top of the 
stack of stack variables of the mOp operands of the de- 
tected instruction of rank i and the n following val- 
ues This permutation operation makes it possible to 
collect at the top of the stack of stack variables the 
^ values to be backed up in the set of new registers ra 
to rn. Stage 514 is followed by a stage 515 consisting 
in inserting, before the instruction of rank x. a set 
of backup instructions store to back up to the set of 
new registers r^ to r„. The abovementioned insertion 
3tage 515 is itself followed by a stage 516 of inser- 
tion, after the det cted instruction of rank i, of a 
set of load instructions load to load from the set of 
new registers r, to r.. lOie set of corresponding inser- 
tion operations is shown in tabl 12 in the annex. 



. 39 - PCI/PB00/0234S 



«0 01/149SS 

, For reasons of oi<npletene»s a»a «itl. rsferen-j 

to fia. 5a. it is indicated U>at. on a ne,ative re- 
sponse to test 504. the continuation of the transfor^a- 
Zon process is i^pl^ented by a context continuation 
,ta«e, continue 503. that the negative response to 
505. 50B, 511 ^ 513 is itself followed ^ a 
continuation of the transformation process v.a a 
text continuation stage, continue 503. and that the 
sa^ applies to the continuation of operations after 
the ahoveMenticnea redirection stages 507 and 510 and 

insertion stages 512 and 516. 

A laore detailed description of the method of 
standardizing and transf owning ^ object code into a 
standardized object code using typed registers as de- 
scribed in fig. 4b will now be given witb reference to 
fig 5b. -mis ii:5>lementation mode concerns . more par- 
ticularly, a nonlimiting. preferred iinplementation nu,de 
of stage 601 to reallocate registers by detecting tbe 
original registers used with different types. 

With reference to the abovementioned fig. 5b, xt 
is indicated that the abovementioned stage 601 consists 
in detexTtdning, in a stage 603. the lifetiiae intervals 
^rked ID, of each register r,. These lifetixae inter- 
vals, designated "live range' or -^bs-, are defined 
for a register r as a maxinnom set of partial traces 
such that register r ie live at all points of these 
traces. For a more detailed definition of these con- 
c^ts, it is useful to refer to the work edited by Ste- 
ven S. MUCHNICK entitled -Advanced Co«s>iler Design and 
ixt^lementation-. Section 16.3, Morgan kaOTMANN. 1997. 
Stage 603 is designated. by the relation: 
iDj< — >rj 

as claimed in which a corresponding lifetime interval 
ID is associated with each register r,. 

The abovementioned stag 603 is followed by a 
stage 604 consisting in determining, at stage 604, the 
«»ain data type. «>arlced tp„ of each lifetime interval 
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jD, The main typ o£ a lifetime interval ID^, for a 
reoister i3 defined by the upper bound of the data 
tvpes stored in thie register r, by the backup instruc- 
tions store belonging to the abovementioned lifetme 

interval, 

stage 604 is itself followed by a stage 605 con- 
sisting in establishing an interference graph between 
the lifetime intervals as defined above at stages 603 
and 604, this interference graph consisting of a non- 
oriented graph of which each peak consists of a Ixfe- 
time interval, and of which the arcs, marked a,..,, on 
f ig 5b, between two peaks ID^i and XDa^, exiet if a .peak 
contains a backup instruction addressed to the register 
of the other peak or vice versa. In fig. 5b, the con- 
struction of the interference graph is shown syinboli- 
calXy. it being possible to in^l««ent this construction 
Oil the basis of calculation techniques which are taiown 
to those skilled in the art. For a more detailed de- 
scription of the construction of this type of graph, it 
is useful to refer to the work published by Alfred V. 
AHO, Ravi SETHI and Jeffrey D. ULLMAN entitled 
•Coiipilers: principles, techniques, and tools", Addi- 
son-Wesley 19B6, Section 9.7. 

Following stage 605. the standardization method 
as shown in fig. 5b consists in translating, in a stage 
606, the uniqueness of a data type which is allocated 
to each register rj in the interference graph, by adding 
arcs between all pairs of peaks of the interference 
graph while two peaks of a pair of peaks do not have 
the same associated main data type. It is understood 
that the translation of the character of uniqueness of 
a data type which is allocated to each register obvi- 
ously corresponds to translating and taking into ac- 
count criterion C4 in the interference graph, this cri- 
terion being mentioned previously in the description. 
The abovementioned stage 606 is th n followed by a 
stage 607 in which an instantiation of the interference 
graph is carried out, this instantiation being nvore 
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cammoxxly deaignated as the painting stage of the inter- 
ference graph as clain^d in the usual technique.. Dur- 
ing stage 607, the transforination proc assigns to 
each lifetime interval ID,, a register nnniber rk, .n 
such a way that two adjacent intervals in the interfer- 
ence graph receive different register nurtibers. 

This operation can he iit«)leniented on the basis 
of any suitable process., as a nonliMting example, it 
is indicated that a preferred process can consist: 

in choosing a peak of nanimum degree in the xn- 
terference graph, roinintmti degree being defxned 
as a minintum number of adjacent peaks, and wxth- 
dxawing it from the graph. This stage can be re- 
peated until the graph is empty, 
b) Each previously withdrawn peak is reintroduced . 

into the interference graph in the inverse order 
of their withdrawal, the last to be removed be- 
ing the first to be reintroduced, and succes- 
sively in the inverse order of the order of 
withdrawal. Thus the smallest register number 
which is different from the numbers assigned to 
all the adjacent peaks can be assigned to each 
reintroduced peak. 
Finally, by stage 602, shown in fig. 4b, the tr^sf cr- 
eation and reallocation process rewrites the access in- 
structions to the registers in the code of the subpro- 
gram of the relevant applet. Access to a given regxster 
in the corresponding lifetime interval is replaced by 
access to a different register, the number of which has 
been assigned during the instantiation phase, also des- 
ignated the painting phase. 

A more detailed description of an on-board data- 
processing system, making it possible to in,>lement the 
n^agement protocol and verification process of a pro- 
gram fragment or applet as claimed in the subject of 
the present invention, and of a development system of 
an applet, will now be given with reference to fig. o. 
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- Regarding the,- corresponding on-boata system with 
reference 10, it is recalled that this on-board system 
is a reprogramn«ble-type system, including the essen- 
tial ^ot^onents as shown in fig. lb- The abovementioned 
on-board system is considered to be interconn cted to a 
terminal by a serial link, the terminal itself being 
linked, for instance via a local network, if appropri- 
ate a remote network, to an applet development corcjmter 
with reference 20. On the on-board system 10 runs a 
xnain prograzn which reads and executes the commands 
which the tentdnal sends on the serial link. Addition- 
ally, the standard commands for a microprocessor card, 
such as for instance the standard commands of the ISO 
7816 protocol, can be i^lemented, and the main program 
recognizes two additional comroands, one for remote 
loading of an applet, and the other for selecting an 
applet which has previously been loaded onto the micro- 

processor card. 

in conformity with the subject of the present 
invention, the structure of the main program is imple- 
nvented in such a way as to include at least one program 
««>dule for management and verification of a downloaded 
program fragment, following the protocol for managing a 
downloaded program fragment as described above in the 
description with reference to fig- 2. 

Additionally, the program module also includes a 
subprogram module to verify a downloaded program frag- 
ment, following the verification method as described 
above in the description with reference to figs. 3a to 

For this purpose, the structure of the memories, 
in particular the non-writable permanent memory ROM. is 
„K,dlfied in such a way as to include in particular, 
apart from the main program, a protocol management and 
verification module 17, as motioned above. Finally, 
regarding the nonvolatile rewritable memory of EEPROM 
type, this advantageously includes a directory of ap- 
plets, marked 18. making it possible to impl^t the 
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n^nagement protocol and .verification process which are 
the subjects of the pr sent invention. 

With reference to the same fig. 6. it indi- 
cated that the applet development system conforming to 
the subject of the present invention, in fact making it 
possible to transform a traditional object code as men- 
tioned above in the description, and satisfying crite- 
ria Cl+C2+C'3+C'4 in the framework of the Java environ- 
Tnent. into a standardized object code for the same pro- 
gram fragment, includes, associated with a traditional 
Java compiler 21, a code transformation module, marked 
22 which proceeds to transform code into standardized 
code as claimed in the first and second inoplementation 
„odes described above in the description with reference 
to figs. 4a, 4b and 5a, 5b. It is in fact understood 
that, on the one hand, standardization of the original 
object code into a standardized object code with 
branching instruction with empty stack and into a stan- 
dardized code using typed registers, on the other band, 
as mentioned previously in the description, makes it 
possible to satisfy verification criteria C3 and C4, 
which are imposed by the verification method which is 
the subject of the present invention. 

The code transformation module 22 is followed by 
a javacard transformer 23, which makes it possible to 
ensure transmission by a remote or local network to the 
terminal and, via the serial link., to the microproces- 
sor card 10. Thus the applet development system 20 
shown in fig- 6 makes it possible to transform the com- 
piled class files produced by the Java compiler 21 from 
the Java source codes of the applet into class files 
which are equivalent, but which observe the additional 
constraints C3, C4 which are imposed by the management 
protocol and the verification module 17 on board the 
microprocessor card 10. These transformed class files 
are transformed into a downloadable applet on the card 
by the standard JavaCard transformer 23. 



various particularly noteworthy conponents of 
the set of protocol cwonents, methods and system^ 
which are the subjects of the present invention will 
now be given for infozmation only. 

compared to the verification processes of the 
prior art as mentioned in the introduction to the de- 
scription, the verification method which is the subject 
Qf the present invention appears noteworthy in that it 
concentrates the verification effort on the typing 
properties of the operands which are essential to the 
security of execution of each applet, i.e. observing 
the type constraints associated with each instruction 
ai.d absence of stack overflow. Other verifications do 
not appear to be essential in ter^ of security, in 
particular verification that the code correctly ini- 
tializes every register before reading it for the first 
•time, on the contrary, the verification method which xs 
the subject of the present invention operates by ini- 
tializing to zero all the registers from the virtual 
machine when the method is initialized, to guarantee 
that reading a non-initialized register cannot compro- 
niise the security of the card. 

Additionally, the demand impoBed by the verifi- 
cation method which is the subject of the present in- 
vention, as claimed in which the stack must be empty at 
each branching or branching target instruction, guaran- 
tees that the stack is in the same state, empty, after 
execution of the branching and before execution of the 
instruction to which the program has branched. This 
mode, of operation guarantees that the stack is in a 
consistent state, whatever the execution route which is 
followed through the code of the relevant subprogram or 
applet- The consistency of the stack is thus guaranteed 
even in the presence of a branching or branching tar^ 
get. contrary to the methods and eystems of th prior 
art, in which it is necessary to conserve in random- 
access memory the type of the stack at each branching 
target, which necessitates a <iaantity of re.ndom-access 



memory proportional to TpxNb. the product of the maxi- 
rm^ size , of execution stack which is used and the num- 
ber of branching targets in the code, the verification 
method which is the subject of the pr sent invention 
5 only needs the type of the execution stack at the time 
of tbe instruction during verification, and it does not 
keep in memory the type of this stack at other points 
of the code, consequently, the method which is the sub- 
ject of the inverition is satisfied with a quantity of 

10 random-access memory proportional to Tp but independent 
of Nb, and consequently of the length of the code of 
the sijbprogram or applet. 

The requirement as claimed in criterion C4, as 
claimed in which a given register must be used with one 

15 and the same type throughout the code of a subprogram, 
guarantees that the abovementioned code does, not use a 
register in an inconsistent way, e.g. by writing a 
short integer to it at one point of tbe program and re- 
reading it as an object reference at another point of 

20 the program. 

In the verification processes which are de- 
scribed in the prior art, in particular in the previ- 
ously mentioned Java specification ^titled 'The Java 
Virtual Machine Specification", edited by Tim LINDHOLM 

25 and Frank YELLHJ, to guarantee the consistency of the 
abovementioned uses through tbe branching instructions, 
it is necessary to keep in random-access memory a copy 
of the table of register types at each branching tar- 
get. This operation necessitates a quantity of random- 

30 access memory proportional to T.xNj,, where T. designates 
the number of registers used by the subprogram and Ife 
the number of branching targets in the code of this 
subprogram. 

On the contrary, the verification process which 
35 is the subject of the present invention operates on a 
global table of register types without keeping a copy 
at diff rent points of the code in random-access mem- 
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ory. consequently, the- xandom-acce^B mempry which is 
r g*ir d to iii5)lement the verification process is pro- 
portional to but independent- of N., and consequently 
of the length of the code of the relevant subprogram. 

The constraint as claimed in which a given reg- 
ister is used with the same type at all points, i.e. at 
every instruction of the relevant code, siinplifies ap- 
preciably and significantly the verification of subpro- 
grams. On the contrary, in the verification processes 
of the prior art, in the absence of such a constraint, 
^ the verification process must establish that the sub- 
programs observe a strict stack discipline, and naist 
verify the body of the subprograms polymorphously re 
garding the type of certain registers. 

in conclusions the verification process which is 
the subject of the present invention, compared to the 
techniques of the prior art, makes it possible, on the 
one hand, to reduce the size of the program code which 
makes it possible to carry out the verification method, 
and on the other hand, to reduce the consvnption of 
random-access memory during the verification opera- 
tions, the degree of corrtplexity being of the form 
0(Tp+Pr) in the case Of the verification process which 
is the subject of - the present invention, instead of 
(0(Tp+Tr)3d!fc) for the verification process of the prior 
art, while however offering the same guarantees about 
the security of execution of the verified code. 

Finally, the process of transforming original 
traditional code into standardized code is inplemented 
by localized transformation of the code without trans- 
mitting additional information to the verifier coirpo- 
nent. i.e. the microprocessor card or on-board data- 
processing system. 

R garding th m thod of reallocating registers 
as described in figs- 4b and 5b, this method differs 
from the known methods of the prior art, as described 
in particular in. US Patents 4,5.71,678 and 5,249,295, by 
the fact thatt 
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the regist r reallocation ensures that the ssm 
register cannot be assigned to two intervals 
\,ith different niain types, which thus guarantees 
that a given register is used with the same type 
throughout the code; and 

the existing register allocation algorithms, 
which are described in the abovementioned docu- 
ments, assuxne a fixed nuittoer of registers, and 
atteiupt to minimize the transfers, called 
''spills\ between registers and stack, whereas 
reallocation of registers as claitfted in the sub- 
ject of the present invention operates in a 
framework where the total number of registers is 
variable, as a consequence of which there is no 
purpose in carrying out transfers between regis- 
ters and stacks when a process of minimizing the 
total number of registers is carried out. 
T?xe protocol for managing a program fragment 
downloaded onto an on-board system, and the methods of 
verifying this downloaded program fragment and of 
transforming this object code of a downloaded program 
fragment respectively, which are the subjects of the 
present invention, can of course be i«5>lemented in 
software. 

Therefore, the present invention also concerns a 
computer program product which can be loaded directly 
into the internal memory of a reprogrammable on-board 
system, this on-board system making it possible to 
download a program fragment consisting of an object 
code, a series of instructions, executable Toy the mi- 
croprocessor of the on-board system by way of a virtual 
machine equipped with an execution stack and with local 
registers or variables manipulated via these instruc- 
tions so that this object code can be interpreted. The 
corresponding con?mter program product includes por- 
tions of Object code to execute the protocol for manag- 
ing a program fragment downloaded onto this on-board 
system, as shown in figs. 2 and 6 described above in 
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the, description, when this on-board system is intercon- 
nected to a t ntdnal and this program is ex cuted by 
the niicroproc asor of this on-board system by way of 

the virtual machine. 

The invention also concerns a corrputer program 
product which can be loaded directly into the internal 
memory of a reprograimable on-board system, such as a 
microprocessor card with a rewritable memory, as shown 
with reference to fig. 6. This conrputer program product 
includes portions of object code to execute the stages 
of verifying a progrcgn . fragment downloaded onto this 
on-board system, as shown and described above in the 
description, with reference to figs- 3a to 33 . lliis 
verification is executed when this on-board system is 
interconnected to a terminal and this program is exe- 
cuted by the microprocessor of this on-board system via 
the virtual machine. 

The invention also concerns a computer program 
product; this computer program product includes por- 
tions of object code to .execute the stages of the 
method of transforming the object code of a program 
fragment into standardized object code for this same 
program fragment, as shown in figs. 4a, 4b. 5a, 5b and 
6. and described above in the description. 

The present invention also concerns a computer 
: program product which is recorded on a medium which can 
be used in a reprogrammable on-board system, e.g. a mi- 
croprocessor equipped with a rewritable memory, this 
on-board system making it possible to download a pro- 
gram fragment consisting of an object code executable 
by this microprocessor, by way of a virtual machine 
equipped with an execution stack and local variables or 
registers manipulated via these rnstructions, to allow 
interpretation of this object code. Th abovementioned 
coimniter program product includ s, at least, a module 
of programs which can be read by the microprocessor of 
■ the on-board system via the virtual machine, to command 
«tecution of a procedare for managing the downloading 
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o£, a downloaded program fragnient, as shown in fig- 2 
and described above in th description, a module of 
programs which can be read by the inicroproc ssor via 
the virtual machine, to command execution of a proce- 
dure for verifying, instruction by instruction, the ob- 
ject code which makes up this program fragment, as 
shown and described in relation to figs. 3a to 3j in 
the description above, and a module of programs which 
can be read by the microprocessor of this on-board sys- 
tem via the virtual machine, to command execution of a 
downloaded program . fragment following or in . the absence 
of a transformation of the object code of this program 
fragment into, a standardized object code for this same 
program fragment, as shown in fig. 2. 
15 The abovementioned computer program product also 

includes a module of programs which can be read by the 
microprocessor via the virtual machine, to command in- 
hibition of execution, on the on-board system, of the 
program fragment in the case of an unsuccessful verifi- 
cation procedure of the abovementioned program frag- 
ment, as shown and described above in the description 
with reference to fig. 2. 
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ANNEXES 



Code of method 
being verified 



aload 0 

sconst 3 
5 aload 
piirfifild C.f 



PdntertolnefrucBon 
being verified 



Table of register types 



short ^ 



Type stack 



Type stack 
pointer 
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TABLE 2 

E>seudo-rCode. of verifier module 
PSgUDO-CODE OF VERIFIER MODULE 
Olobal variables used: 



TV 


numb^ of registere declared by current method 


rp 


maximum sire of stack declared by cunent method 


trfTrJ 


table of register types (402 in fig. 4) 




stack type (403 m fig. 4) 


PP 


stack pointer (404 in fig. 4) 


chg 


flag indicating whether tr has changed 



Initialkcfi/F-^O 

Initialize ip(0] ... ip[n-l) froiu types of n arguments of method 
Initialize ipW - ip[7>l] to J- 
Initialize c/i;p to tnie 
While ehg is true: 

Reset cAff to false 

Position on first inscmcdon of method 
While end of meUiod is not reached: 

If current instniction is target of a l^^nching instruction: 

If pp it 0, verification fails 
If current instruction is target of a subroutine call: 

If previous instruction continues in sequence, failure 

Take g^EOJ^^-etaddr andpp^l 
If cuuem instruction is an exception handler of class O 

If previous instruction continues in sequence, failure 

Do tp[0]^ C and pp^l 
If cUfTCTt instruction is a target of different kinds: 

Verificadon fells 
Determine type& a; ... Oq of arguments of instruction 
If pp < n. failure (stack overflow) 
For/=l, — , n: 

If tplpp-n-i-I] is not subtype of a*, failure 
Dopp^ppm 

Determine types o, of results of instruction 
If pp^n^p, failure (stack overflow) 
For f = 1 , « m, do tp\pj>¥U 1 J 7 r, 

If current hKtnKtion is a write to a register. 
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Detcnnine ?ype / of value written to record 
Do trlr]4-lawerbaund(utr[r]) 
Utrlr] has changed, do chg^bniC 

If cuirent rostniction is a banchmg: 
If PP#0, verification failure 

Advance to next instruction 
Rfitum vcrificalion success code 



TABLE T3 

static ehoTzQ aethC^hort □ table ) 
{ 

short □ result = null; 
if ( table length 2) result = table; 
return table 

> 
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Flirst iteration on method code: 




Method code 


U ' 






asTore X j 


2: 


aloaii 0 j 


3: 






4 -• 


" sctaisx 2 




6: 






7 : 


aload 0 


::): 


8: 






9: 


Sload 1 




10: 


aretvtn 





Table of re gister typw_ 

— — — xi: r 



stack type 



Second Iteration on method code: 



0: 


aconst^null 


1 : 




2: 


aload 0 


3: 


ajrray length 


4 : 


ficcast 2 


5 : 




7 ; 


alo^d 0 

- 


8: 




9: 


aloftd 1 


10: 


aretum 



po-. skertUlTArj^^ 

.faarxLJIrl; aitogt^ I 

[wir 8iiBrtU|rt; *kag^U3 G 

...J... frorS *'ag»Ll»gl' «hgiuj 
. [■a" short U i-'*= abortlJI 
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i&) Violation of type constraims on arguments cf an instruction: 

\ iQ: Object"! I 



0 : 


aload 0 


1 : 


sconst 1 


2 : 


S&dd 


3 : 





tO; Object 1 fOhliect \ 



Error stack type does not 
correspond to what Instruction 
expects (short, short) 



(b) Inconsistent use of a register: 



0 
1 
4 
5 
6 
7 



{ rO: Bliortl I 
[ rO; short") j shon \ 




Error stack type does not correspond 
to what instruction expects (Object) 



(c) Branchings Introducing inconsistencies at stack level: 

. frtf; 5heT=t I ) 

■ \ rOi sbcrTI t abwrt t 

I 

short I \ &hcrt~| 



0: 


Blasd 0 


1 : 


if eq 8 - 


4: 


SCOBSt 1 


3 : 


geio 9 


8: 




9: 





Error stack not empty at branching point 



(d) Stack overflow within a loop: 



0; 


sload 0 


1 : 


iieq 31 * 


4 : 


sconst 1 


5 : 


. si&c 0 -J 


8: 


goto 0 


11 ; 


return j 



rP: gbort I \ abort | 

.- ( rO: short i I _ 

•• | rO: sberTI f itbert~| 

:. | rO: «A. rx 1 f ^b rt J 



Em)r Stack not mpty at branching point 



TABLE T6 



0 
1 
4 

m 

D 
8 

9; 
10: 
11 : 
12: 



aload 0 


I WJV^b 1 


: ifniill 8 ^ 




icotist 1 




goto 9 - 


•'•{ ro: olS'jm 1 


iconst 0 


iro: Qi>i«ct 1 






iatore 0 




iJLoad 0 
irerum 


1 rO: aat 1 



TABLE T7 

(b) Af.rA«/cc& ^erstandardi^n of stack at branching^ -^9; 




Lr%t: uajtet { rl; J. 1 



1 ror Obl<et 



rl: J. 



1 I 



i- -i J [ ittt' 1 



fry; upjact | rr|jnr " [ | 

1 rv: i^oiect > rl: ±' | j 

i'ru: dbjeet |rl; int ] j 

f rO: Ubjeet | rl^jat -| | j^^ \ 

ru; lat < rl: int ") | 



jIABLB T8 

Xc): Method coiiecfier reaUoeation of register: 



0: 


aload 0 


1 : 


ifnull 8 ~ 


4 : 


iconsx 1 


4': 


istore I 


5 : 


goto 8" - 


8 : 


i const b 


8' ; 


istore 1 


S" ! 


iload 1 


9: 


ineg 


10: 


Istore 1 


n : 


iload 1 


12; 


ir«tux3x 



•j rO: Object \ 


rl; 


1 






•( rO: Object J 


ri: 


X 


1 


-1 rO: Obj ct 1 


rl: 


1 


1 




•1 rO: Object | 


rl: 


X 






•1 rO: Object ) 


rl: 


xnx 






•| rC: Object i 


rl: 


int 




-1 rO: Object | 


rl: 




' 1 


•1 Oi>3«« 1. 


rl: 


ini 


1 


■1 rO: Object | 


rl: 


iaz 


1 


'1 rO: Object | 


rl; 


int 


1 


-1x0: Object f 


rl: 


int" 


"1 


lO: Otject 


rl: 


int 


1 



int I 



int ) 
int 1 



TABLE T9 

{^} Branching target, previous instruction not continuing in sequence: 
Branching Brant*fng 



noh-seq. tnstr, 



stack stat8 

03 



Standardization 



non-eeq. instr. 



load 



instruction i 



-stack stste 

I 



TABLE TIP 

(Jb) Branching target, previous instruction continuing in sequence: 
Branching ( Branching 



seq. instr. 



ijkstructios) i 



EE 



Standardization 



aaq. Instr. 



store r2 



siore n 



load Ti 



Insiroctkai 



EE 
i 

E3 



TABLE Til 

(c) Unconditional branching without arguments: 

Standarcfization 



goto 



T 

Target 



Target 



store Ti 
goxo 



EE 
I 



TABLE T12 • 
1 0 (c) Conditional branching with one argument: 



Target 



Standardization 



{org 



r 

Target 



svap.x 2,1 

8toro rx 

load n 
load r2 



l£]£} 

I 



i CLAIMS 

1. A protocol for managing, a program fragment 
clownlpaded onto a reprogrammable on-board system^ euch 
as a microprocessor card equipped with a rewritable 
memory, said program fragment consisting of an object 
code, a series of instructions, executable by the mi- 
croprocessor of the on-board system by way of a virtual 
machine equipped with an execution stack and with local 
variables or registers manipulated via these instruc- 
tions and making it possible to interpret this object 
qode, said on-board system being interconnected to a 
terminal, characterized in that this protocol consists 
at least, at the level of said on-board system: 

a) in detecting a command for downloading of this 
program fragment; and, on a positive response to 
this stage consisting in detecting a downloading 
command, 

b) in reading the object code constituting this 
program fragment and in temporarily storing this 
object code; 

c) in subjecting the whole of the object code 
stored teirpprarily in memory to a verification 
process, instruction by instruction, this veri- 
fication process consisting at least in a stage 
of initializing the type stack and the table of 
register types representing the state of said 
virtual machine at the start of the execution of 
the ten5)orarily stored object code and in a suc- 
cession of stages of verification, instruction 
by instruction, by discerning the existence, for 
each current instruction, of a target, branch- 
ing-instruction target, target of an exception- 
handler call, or target of a subroutine call, 
and in a verification and an xipdating of the ef- 
fect of said current instruction on th type 
stack and on the table of register types, and, 
in the event of a successful verification of 
said object coc:e. 



d) : in recording the' dovmloaded progrOTi fragment 

a directory of available program fragments, and* 
in the event of an unsiacc saful verification of 
said object code, 

e) in inhibiting ex cution, on said on-board sys- 
tem, of said program fragment. 

2* ThQ protocol as claimed in claim 1, charac- 
terized in that said stage e) of inhibiting the execu- 
tion consists: 

f ) in deleting the momentarily recorded program 
fragment, when omitting to record the latter in 
said directory of available program fragments, 
and 

g) in sending an error code to said reader. 

3. The protocol as claimed in claim 1 or 2, char- 
acterized in that, on a negative response to said stage 
a) consisting in detecting a downloading command, this 
consists: 

b') in detecting a command to select an available 

program fragment from a directory of program 
fragments; and, on a positive response to this 
stage, consisting in detecting a command to se- 
lect an available program fragment; 

c') in calling said selected available program frag- 
ment; 

d') in executing said called available program frag- 
ment via the virtual machii;ie, with no dynamic . 
verification of variable types, access rights to 
the objects which are manipulated by the called 
available program fragment, or overflow of the 
execution stack when each instruction is exe- 
cuted, and, on a negative response to this stage 
consisting in detecting a command to select an 
available program fragment, 

e') in proceeding to process the standard commands 
of the on-board system. 

4. A method ■ of verifying a program fragment 
downloaded onto a repr grammable on-board aystem, such 



as a r^iicroprocessor card equipped with a rewritable 
memory, said program fragment consisting of an object 
code and including at least one subprogram^ a aeries of 
instructions^ by the microprocessor of the on-board 
5 system by way of a virtual machine equipped with an 
execution stack and with operand registers manipulated 
by these instructions, and making it possible to inter- 
pret this object code, said on-board system b^ing in- 
terconnected to a reader, characterized in that said 
10 method, following the detection of a downloading com- 
mand and the storage of said object code constituting 
this program fragment in said rewritable memory,, con- 
sists, for each subprogram: 

a) in carrying out a stage of initializing the type 

15 stack and the table of register types by data 

representing the state of the virtual machine at 
the start of the execution of the temporarily 
stored object code; 
p) in carrying out a verification of said temporar- 

20 ily stored object code instruction by instruct 

tion, by discerning the existence, for each cur- 
rent instruction, of a target^ a branching- 
instruction target, a target of an exception- 
handler call or a target of a subroutine call; . 
25 y) in carrying out a verification and an updating 

of the effect of said current instruction on the 
data types of said type stack and of said table 
of register types, on the basis of the existence 
of a branching-instruction target, of a target 
30 of a subroutine call or of a target of an except 

tion'-handler call, said verification being sue 
cessful when the table of register types is not 
modified in the course of a verification of all 
the instructions,, and the verification process 
35 being carried out instruction by instruction un- 

til the tabl of register types is stable^ with 



no modification present, the veriff cation proc- 
ess being interrupted otherwise. 

5. The V rification method as tlaimed in claim* 
4, characterized in that the variable typ s which ar 

5 manipulated during the v rification proc ss includ at 
1 ast: 

class identifiers corresponding to object 
classes which are defined in the program frag- 
ment; 

10 - numeric variable types including at least a type 

short , an integer coded on p bits, and a type 
retaddr for the return address of a jump in- 
struction JSR; 

a type null relating to references of null ob- 

15 jects; 

a type object relating to objects; 
a first specific type representing the in- 
tersection of all the types and corresponding to 
the value 0, nil; 

20 - a second specific type T, representing the union 

of all the types and corresponding to any type 
of value. 

6. Method as claimed in claim 5, characterized 
in that all said variable types verify a subtyping re- 

25 lation: 

object eT; 

short , retaddr e T; 
J^e null / short , retaddr , 

7. The method as claimed in one of claims 4 to 
30 6/ characterized in that when said current instruction 

is the target of a branching instruction, said verifi- 
cation method consists in verifying that the type stack 
is ea5)ty, the verification process being continued for 
the following instruction in the case of a positive 
35 verification/ and the . verification process failing and 
the program fragment being r jected otherwise* 



8. Th method asj. claimed ifi one of claims 4 to 
7; Gharacterizejia.in ti^t when said current instruction 
is th target of a subroutine call, said verification 
process verifies that the previous instruction is an 

5 unconditional branching, a subroutine return or a rais- 
ing of an exception, said verification process, in the 
case of a positive verification, proceeding to reupdate 
the stack of variable types by an entity of retaddr 
type, the return address of the subroutine, and the 
10 verification process failing and the program fragment 
being rejected otherwise. 

9. The method as claimed in one of claims 4 to 

8, characterized in that when the current instruction 
is the target of an exception handler, said verifica- 

15 tion process verifies that the previous instruction is 
an xaiconditional branching, a subroutine return or a 
raising of an exception, said verification process, in 
the case of a positive verification, proceeding to re- 
update the type stack by entering the exception type, 

20 and the verification process failing and the program 
fragment being rejected otherwise. 

10. The method as claimed in one of claims 4 to 

9, characterized in that when the current instruction 
is the target of multiple incon^patible branchings, the 

25 verification process fails and the program fragment is 
rejected. 

11. The method as claimed in one of claims 4 to 

10, characterized in that when the current instruction 
is not the target of any branching, the verification 

30 process continues by passing to an update of the type 
stack. 

12. The method as claimed in one of claims 4 to 

11, characterized in that the stage of verification of 
the effect of the current instruction on the type stack 

35 includ s, at least: 

a stage of verifying that the type execution 
stack includes at least as many entries as the 
current Instruction includee operands; 



. a stage of unstaclcing and of verifying that the 
types , of the entries at the top of the stack are 
fiiibtypes of the types of th operands of the op- 
erands of this instruction; 
5 _ a stage of verifying the existenc of a suffi- 

cient memory space on the typ stack to proceed 
to stack the results of the current instruction; 
a stage of stacking on the stack data types 
which are assigned to these results. 

13. The method as claimed in claim 12, charac- 
terized in that when the current instruction is an in- 
struction to read a register of address n, the verifi- 
cation process consists: - - — 

in verifying the data type of the result of this 
15 reading, hy reading the entry n in the table of 

register types; 

in determining the effect of the current in- 
struction on the type stack by unstacking the 
entries of the stack corresponding to the oper- 
20 ands of this current instruction and by stacking 

the data type. of this result. 

14. OSie method as claimed in claim 12, charac- 
terized in that when the current instruction is an in- 
struction to write to a register of address m, the 

25 verification process consists: 

in determining the effect of the current in- 
struction on the type stack and the type t of 
the operand which is written in this register of 
address m; 

30 - in r^lacing the type entry of the table of reg- 

ister types at address m by the type immediately 
above the previously stored type and above the 
type t of the operand which is written in this 
register of address m. 



15. A method of tiransforming an object code of a 
program tragisvmt, in which the operands of each in- 
struction belong to the data types manipulated by this 
instruction, the execution stack does not exhibit any 
5 overflow phenomenon, for each branching instruction, 
the type of the stack variables at this branching is 
the same as at the targets of this branching, into a 
st^dardized object code for this same program frag- 
ment, in which the operands of each instruction belong 
10 to the data types manipulated by this instruction, the 
execution stack does not exhibit any overflow phenome- 
non, the execution stack is &apty at each branching in- 
struction and at each branching- target instruction, 
characterized in that this method consists^ for all the 
15 instructions of said object code: 

in annotating each current instruction with the 
data type of the stack before and after execu- 
tion of this instruction, the annotation data 
being calculated by means of an analysis of the 
20 data stream relating to this instruction; 

in detecting, within said instructions and 
within each current instruction, the existence 
of branchings , or respectively of branching- 
targets, for which said execution stack is not 
25 empty, the detection operation being carried out 

on the basis of the annotation data of the type 
of stack variables allocated to each current in- 
struction, and in the presence of detection of a 
non-eni>ty execution stack, 
30 - in inserting instructions to transfer stack 

variables on either side of these branchings or 
of these branching targets, respectively in or- 
der to exttpty the contents of the execution stack 
into temporary registers before this branching 
35 and to reestablish the execution stack from said 

teir^porary registers after this branching, and in 
not inserting any trans f r instruction other- 
wise, making it possible to obtai«.i a st an da r d- 



■ iz d obi ct code for this s^e program fragment, 
in wMch th execution stack is enpty at each 
branching instruction and at each branching- 
target instruction, in the absence of any modi- 
fication to the ex cution of said program frag- 
itient- 

. 16. A n«thod of tt«.s£o»ing an object code of a 
program fra9»ent. in which the operands of each ^- 
stnxctio^ belong to the data types manipulated to thxe 
i^truotion. and an operand of giv«. type written into 
a register by an instruction of this object code re- 
read from this same register by another instruction of 
this object code with the same given data. type, mto a 
standardised object code for this sa»e progran frag- 
^t, in which the oper«>ds of each instruction belong 
to the data types numipulated by this instruction, the 
sa.»e data type being allocated to the same register 
throughout said standardized object code, .characterized 
in that this method consists, for all the instructions 

of said object code: 

in annotating each current instruction wxth the. 
data type of the registers before and after exe- 
cution of this instruction, the annotation data 
being calculated by means of an analysis of the 
data stream relating to this instruction; 
in carrying out a reallocation of the registers, 
by detecting the original registers ea«)loyed 
with different types. ^ dividing these original 
registers into separate standardized registers, 
one standardized register for each data type 
used, and reupdating the instructions which ma- 
nipulate the operands which use said standard- 
ized registers- 

17 «.e method as claimed in claim 15. charac- 
terized in that the stage .consisting in detecting, 
^thin said instructions and within each current in- 
struction, the existence of branchings, or respectively 
of branching targets, for vhich the ex cution stack is 



Xioi^ &nptv, consists, fOllcwing .detection of ea<di corr - 
sponding instnidtion 'of rank i: 

_ : in associating, with, ach instruction of rank i a 

set of nevf registers, one new regist r being as- 
sociated with ach stack variable which is ac- 
tive at this instruction; 

in examning each detected instruction of rank i 
and in discerning the existence of a branching 
target or branching, respectively, and, in the 
case where the instruction of rank i is a 
branching target and that the execution stack at 
this instruction is not einpty, 

• for every preceding instruction, of rank 

i-1, consisting of a branching, a rais- 
ing of an exception or a program return, 
the detected instruction of rank i being 
accessible only by a branching, 
in inserting a set of load instructions 
• load to load from the set of new regis- 
ters before said detected instruction of 
rank 1, with redirection of all branch- 
ings to the detected instruction of rank 
i to the first inserted load instruction 
load ; and 

for every preceding instruction, of rank 
i-1, continuing in sequence, the de- 
tected instruction of rank i being ac- 
cessible simultaneously by a branching 
and from the preceding instruction of 
rank i-1, 

in inserting a set of backup instruc- 
tions store to back up to the set of new 
registers before the detected instruc- 
tion of rank i, and . a set of load in- 
structions load to load from this set of 
new registers, with redirection of . all 
the branchings to the detected instruc- 



tion of. rank i to the first inserted 
/ load instruction load, and, in th cas 
where said detected instruction of rank 
i ie a branching to a given instruction., 
for every d tected instruction of rank i 
consisting of an unconditional branch- 
ing. 

in inserting, before the detected in- 
struction of rank i, multiple backup in- 
structions store , a backup instruction 
. being aeeociated with each new register; 
and 

for every detected inst-ruction of rank i 
consisting of a conditional branching, 
and for a nuitiber m > 0 of operands ma- 
nipulated by this conditional branching 
instruction, 

in inserting, before this detected in- 
struction of rank i, a permutation in- 
20 struction, swap-x , at the top of the 

execution stack of the xn operands of the 
detected instruction of rank i and the n 
following values, this perroutation op- 
eration making it possible to collect at 
25 the top of the execution stack the n 

values to be backed up in the set of new 
registers , and 

in inserting, before the instruction of 
rank i. a set of backup instructions 
30 store to back up to the set of new reg- 

isters , and 

in inserting, after the detected in- 
struction of rank i, a set of load In- 
structions load to load from the set of 
35 new registers. 

18. laxe method as claimed in claim 16, charac- 
teri:.ed in that the stag cons.sti^g in r allocating 



10 



15 



registers by detecting W original registers eiT«>loyea 
witV <^^f«rent typ s cianfiifits: 

_ y in d t rmining the lif time intervals of ach 
register; 

in determining the main data type of each lif - 
time interval, the main data type of a lifetime 
interval j for a register r being defined by the 
upper bound of the data types stored in this 
register r by the backup instructions store be- 
longing to the lifetime interval j; 
in establishing an interference graph between 
the lifetime intervale, this interference graph 
consisting of a non-oriented graph of . which each 
peak consists of a lifetime interval, and of 
which the arcs between two peaks ji and jz exist 
if a peak contains a backup instruction ad- 
dressed to the register of the other peak or 
vice versa; 

in translating the uniqueness of a data type 
which is allocated to each register in the in- 
terference graph, by adding arcs between all 
pairs of peaks of the interference graph while 
two peaks of a pair of peaks do not have the 
same associated main data type; 
_ in carrying out an instantiation of the inter- 

ference graph, by assigning to each lifetime in- 
terval a register number, in such a way that 
different register numbers are assigned to two 
adjacent life intervals in the interference 

30 graph. 

19. An on-board system ^ich can be reprogrammed 

by downloading program fragments, including at least 
one microprocessor, one random^access memory, one xn- 
put/ontput modul , one lectrically reprogrammable non- 
35 volatile memory and one permanent memory, in which ar 
installed a main program and a virtual machin which 
^kes it possible to execute the main program and at 
least on program- fragment using said microprocessor. 



20 



25 



leSt one proBX^ -o*.! " .^..g -ri^y a do» 

Xoadea program fr.^t. «id :»na.e,»nt and verxf .ca- 
tion program n»a»le being installed i« the permanent 

20 *n on^board ayste. which can be reprogra^ed 
^ downloading program fragments, including at least 
one .nicroprocessor. one randoM-accesa »e»ory. one^- 
put/output module, one electrically r^rogra»«able non- 

tilfn^nory and one pen^«>t »«»ry, ^ 
installed a »ain program and a virtual J*^* 

it possible to execute the Min program and 
l.ast one progr«. fragn«nt using .aid..>nicropro^ssor. 
Characterized in that said on-board syst^n 
least one program module to .^nage and verify a down- 
loaded program frag>nent in accordance with the protoc^ 
^or managing a downloaded program frag.nant as cla»ed 
i„ one of clai™ 1 to 3, said ™.age»«nt and verxfxca- 
tion program module being installed in the permanent 

21 ^e on-board syst«. as clain^d in clai» 20. 
Characterized in that it include, at least ^one 
3ra» module to verify a downloaded program £ragi>^t in 
tocordancB with the verification process as cXal.»ed in 

one of claims 4 to 14. ^ t . 

22. A method of transforming an object code of a 
program fragment, which the operands of ead. ^- 
etx^tion belong to the data types -^^^"'^.^^^ 
instruction, the execution stack does not exhibit any 
„,„flc„ phenomenon, for each br«>ching ^-^'^^'^ 
the type of stack variable, at this branching « the 
s«.e as at the targets of this branching, «.d ^ ^- 
a„a of giv«. type written to a register by an «struc- 
tion of this object code is reread from this same reg- 
ist r by another instruction of this object cod with 
.1 given data typ . into a standardised object 
code for this same progr-. fragment, in which the oper- 
^„ Of each instruction belong to the data types ma- 
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20 
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35 



xaipuiated by tk±s instruction, the execution stack does 
not e3du.bit overflow ph^omenon, the execution stack is 
en^pty at each branching instnaction and at each branch- 
ing-target instruction, the same data type being as- 
signed to th same register throughout said standard- 
ized object code, characterized in that said conversion 
system includes, at least, installed in the working 
memory of a development coirputer or workstation, a pro- 
gram module to transform this object code into a stan- 
dardized object code in accordance with the method as 
claimed in one of claims 15 to 18, making it possible 
to generate a standardized object code for said program 
fragment, satisfying the criteria for verifying this 
downloaded program fragment. 

23. A coinputer program product which can be 
loaded directly into the internal memory of a repro- 
grammable on-board system, such as a microprocessor 
card equipped with a rewritable memory, this on-board 
system making it possible to download a program frag- 
ment consisting of an object code, a series of instruc- 
tions, executable by the microprocessor of the on-board 
system by way of a virtual machine equipped with an 
execution stack and with local variables or registers 
manipulated via these instructions and making it possi- 
ble to interpret this object code, this computer pro- 
gram product including portions of object code to exe- 
cute the protocol for managing a downloaded program 
fragment on this on-board system as claimed in one of 
claims 1 to 3, when this on-board system is intercon- 
nected to a terminal and this program is executed by 
the microprocessor of this on-boax^ system by way of 

said virt\ial machine. 

24. A consniter program product which can be 
loaded directly into the internal memory of a repro-- 
grammable on-board system, such as • a microprocessor 
card equipped with a rewritable memory, this on-board 
system making it possible to download a program f rag- 

. „^t consisting of an objoct code, a series of instruc 
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tioas, executaiill^ by the »icrop«oc ..or pf t* on-board 
sviti. inr Wot a '^^^ equiBPea with » 

^ecution stack and with operand registers manipulated 
via these instrxictions and makina it posslbl to inter- 
pret this, obj ct code, this computer prograia product 
including portions of object code to execute the stages 
of verifying a program fragn>ent downloaded onto thxs 
on-board syet«. as clai»«i in one of claims 4 to 14. 
when this on-board system is interconnected to a termi- 
ni and this program is executed by the microprocessor 
of this on-board system by way of said virtual machine. 

26. A computer program product including por- 
tions of object code to execute stages of the method of 
..^sfor^g an object code of a 

fragment into a standardized ohject code for t^s aa^ 
program fragment as claimed in one of =laa«s 15 to 18 

26 . A computer program product which is recorded 
on a medium which can be used in a 

board system, such as a microprocessor card shipped 
with a rewritable memory, this on-board system mak^ 
it possible to download a program frag»«.t consisting 
of L <*ject code, a series of instructions, «c.cutable 
by the Kdcroprocessor of the on-board system by «y of 
r virtual n^chine e<MPP.d with an execution stack and 
with local variables or registers manipulated via th«se 
l^r^ctions and n^ing it possible to ^^^'^^ 
Object code, this co«^ter program product including, 

at least: . 

program resources which can be read by the m- 
croprocessor of this on-board system via said 
virtual machine, to con«»and execution o£ a pro- 
cedure for managing the downloading of a down- 
loaded program fragment; 

program resources which can be read by the »d- 
crc*rocesBor of this on-board system via said 
virtual machine, to command execution of a- pro- 
cedure for verifying, instruction by instruc- 
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tion, the object code which mak s up said pro- 

program xeBOurceB which can be read by the ml- 
croprocesBor of this on-board system via said 
virtual machine, to command execution of a down- 
loaded program fragment following or in the ab- 
sence of a conversion of the object- code of this 
program fragment into a standardized object code 
for this same program fragment. 
27. The conputer program product as claimed in 
claim 26, additionally including program resources 
which can be read by the microprocessor of this on- 
board system via said virtual machin?. to command inhi- 
bition of execution, on said on-board system, of said 
program fragment in the case of an unsuccessful verifi- 
cation, procedure of this program fragment. 
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